bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Generic Junctions (was: Re: Channel sessions)


From: olafBuddenhagen
Subject: Generic Junctions (was: Re: Channel sessions)
Date: Mon, 3 Sep 2007 02:36:24 +0200
User-agent: Mutt/1.5.16 (2007-06-11)

Hi,

On Fri, Aug 24, 2007 at 02:14:38PM +0200, Carl Fredrik Hammar wrote:
> <olafBuddenhagen@gmx.net> writes:

> First a slight change in terminology, I will call an in-tee a
> `broadcast' and an out-tee simply a `tee'.

Well, for one, "broadcast" doesn't really fit here strictly speaking --
multicast seems more appropriate.

More importantly, I'd actually suggest the opposite: A
broadcast/multicast is an outgoing message that the sender (the client)
sends out to multiple receivers. That is what the out-tee does. (You
could argue that an in-tee distributes the message from one device to
several clients... But if you look from the device perspective, you
would actually have to swap the meanings of input and output. Of course,
that would also swap the meaning of in-tee/out-tee, so
broadcast/multicast would again be the equivalent of out-tee...
Broadcast/Multicast is inherently about output :-) )

While I quite like the broadcast or multicast term, I wonder whether
it's not better to keep the more unambiguous terms...

> > Yeah, we probably need a "generic" package with some universal
> > modules that should suffice to handle simple devices not having
> > special needs. But I don't think this package will be very large:
> > What does it require besides the mach device access and buffering
> > hub types?
> 
> I would think that broadcast and a front-end fifo might be useful to
> get around exclusive access input devices and perhaps /dev/random.

Well, if for some device multiplexing is straightforward (not
requirering sophisticated mechanisms like sound or networking), so it
could use a generic junction, there is probably no reason not to
implement multiple access directly in the kernel device, I'd say...

-antrik-




reply via email to

[Prev in Thread] Current Thread [Next in Thread]