On Tue, 11 Jun 2002, Terry Lambert wrote:
TL>Harti Brandt wrote:
TL>> I was talking about real devices, not pseudo devices that you can get out
TL>> of thin air. Device driver for real devices should be just what they are:
TL>> device drivers. If you take a disk driver, then there is no code there
TL>> that tries to present multiple contexts to multiple openers - supporting
TL>> this is the task of the file system. If you take a sound card, the
TL>> multiplexing stuff, that handles multiple processes open the soundcard
TL>> should not be in the driver, but in the abstraction above. The same holds
TL>> for the network devices. The situation is different for pseudo devices
TL>> which you can create on demand.
TL>This is true for most real devices, but not all of them.
TL>For a disk device, it would be nice if I could ioctl() it to change
TL>it's instance to that of a parent, e.g. for "slice management".
Can't see any 'cloning' here.
TL>For a sound device, it would be nice if multiple instances to the
TL>devices were mux'ed. I've had cases where the program I was using
TL>was using a smaller number that the total available channels, and
TL>it would have been nice if the next open instance got the remaining
TL>channels, rather than a "device in use" error. You'd have to manage
TL>this by giving all remaining available channels to an opener, and
TL>then having them ioctl() the unused ones back (e.g. "allocate N"
TL>when there are M available, means "give M-N back").
That has also nothing to do with cloning. Look at the current pcm driver -
it just has a device entry per channel. Where cloning could come into the
play is when more than one process tries to open a 1-channel device and
you want to mix the audio. As I said this would be a task of a layer above
the sound driver (just as X 'multiplexes' N processes onto one display
device). Unfortunately there is no good sound API up to now.
TL>For a DVD, it would be nice if you could select the instance of the
TL>device you were going to get for seperation of the ISO9660 and UDF
TL>FS's (e.g. which record boundary the device actually used). The way
TL>that OS X supports this is by doing DVD mounts on both the character
TL>and block device seperately. For FreeBSD, UDF support, which has to
TL>have access to the ISO9660 FS for the purposes of index access, is
TL>much more messy.
No cloning here.
TL>You could also make an argument for multiple input devices and the
TL>management of which one you get when you open /dev/mouse.
Again you just get it the wrong way around. You need per process/open
context if you try to put the multiplexing of ONE mouse between MULTIPLE
processes into the hardware mouse driver. Again this would be plain wrong.
TL>Finally, there's a long history on SCO Xenix and UNIX, starting with
TL>"Computone" multiport serial cards, of multiplexing access to the
TL>device seperately for printing vs. terminal I/O. Yes, Digiboard and
TL>other vendors handle this by having two device nodes for a single
TL>pgysical device, and maintaining a state machine for the escape
TL>sequences. But this is really a matter of preference, not necessity.
TL>Writing to one instance, you talk to the terminal, and writing to the
TL>other, you talk to the "aux" port.
Again this is not about 'cloning a physical' device.
TL>I don't think the original poster wanted cloning for support on
TL>physical devices for which there was a 1:1 relationship anyway
TL>(8^)), but there *are* cases where it could be useful.
TL>Actually, I think the original poster never really disclosed *what*
TL>they wanted to use the feature for...
>From reading the original post I was under the impression that this is
again a 'hey, I write a device driver and I need to track the number of
opens and to tack a context onto each open' that periodically comes up.
If I'm wrong, well, sorry then...
harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message