Harti Brandt wrote:
> I was talking about real devices, not pseudo devices that you can get out
> of thin air. Device driver for real devices should be just what they are:
> device drivers. If you take a disk driver, then there is no code there
> that tries to present multiple contexts to multiple openers - supporting
> this is the task of the file system. If you take a sound card, the
> multiplexing stuff, that handles multiple processes open the soundcard
> should not be in the driver, but in the abstraction above. The same holds
> for the network devices. The situation is different for pseudo devices
> which you can create on demand.

This is true for most real devices, but not all of them.

For a disk device, it would be nice if I could ioctl() it to change
it's instance to that of a parent, e.g. for "slice management".

For a sound device, it would be nice if multiple instances to the
devices were mux'ed.  I've had cases where the program I was using
was using a smaller number that the total available channels, and
it would have been nice if the next open instance got the remaining
channels, rather than a "device in use" error.  You'd have to manage
this by giving all remaining available channels to an opener, and
then having them ioctl() the unused ones back (e.g. "allocate N"
when there are M available, means "give M-N back").

For a DVD, it would be nice if you could select the instance of the
device you were going to get for seperation of the ISO9660 and UDF
FS's (e.g. which record boundary the device actually used).  The way
that OS X supports this is by doing DVD mounts on both the character
and block device seperately.  For FreeBSD, UDF support, which has to
have access to the ISO9660 FS for the purposes of index access, is
much more messy.

You could also make an argument for multiple input devices and the
management of which one you get when you open /dev/mouse.

Finally, there's a long history on SCO Xenix and UNIX, starting with
"Computone" multiport serial cards, of multiplexing access to the
device seperately for printing vs. terminal I/O.  Yes, Digiboard and
other vendors handle this by having two device nodes for a single
pgysical device, and maintaining a state machine for the escape
sequences.  But this is really a matter of preference, not necessity.
Writing to one instance, you talk to the terminal, and writing to the
other, you talk to the "aux" port.

I don't think the original poster wanted cloning for support on
physical devices for which there was a 1:1 relationship anyway
(8^)), but there *are* cases where it could be useful.

Actually, I think the original poster never really disclosed *what*
they wanted to use the feature for...

-- Terry

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to