Date: Tue, 11 Jun 2002 11:48:27 +0200 (CEST) From: Harti Brandt <brandt@fokus.gmd.de> To: Terry Lambert <tlambert2@mindspring.com> Cc: Maksim Yevmenkin <m_evmenkin@yahoo.com>, <current@FreeBSD.ORG> Subject: Re: Device cloning Message-ID: <20020611114039.L35453-100000@beagle.fokus.gmd.de> In-Reply-To: <3D05C414.D3B5F0C0@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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> TL>This is true for most real devices, but not all of them. TL> 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> TL>Actually, I think the original poster never really disclosed *what* TL>they wanted to use the feature for... That's true... 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 -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private brandt@fokus.fhg.de 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?20020611114039.L35453-100000>