Date: Tue, 11 Jun 2002 02:34:12 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Harti Brandt <brandt@fokus.gmd.de> Cc: Maksim Yevmenkin <m_evmenkin@yahoo.com>, current@FreeBSD.ORG Subject: Re: Device cloning Message-ID: <3D05C414.D3B5F0C0@mindspring.com> References: <20020611103826.W35132-100000@beagle.fokus.gmd.de>
next in thread | previous in thread | raw e-mail | index | archive | help
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 majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3D05C414.D3B5F0C0>