Date: Tue, 11 Jun 2002 11:35:58 -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: <3D06430E.D58FF87A@mindspring.com> References: <20020611114039.L35453-100000@beagle.fokus.gmd.de>
next in thread | previous in thread | raw e-mail | index | archive | help
Harti Brandt wrote: > 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. A device entry per channel is a stupid idea. It means that I can not write software to "open the sound device", I have gto write software to "open the *right* sound device out of N sound devices, so that I get the right channel". It's a lot easier to just open the thing, than it is to teach every single piece of software that uses sound to do the "right" thing, and know how to do that. If nothing else, it wil mean an incredible duplication of code in all sound using user space programs, and programs written by naieve programmers (yeah, I know -- like rattus giganticus, they don't exist, right) so that "if you want to run A and B, you have to run B first, because B doesn't know aboout anything but the first sound device". This is just a recipe for disaster. > 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. If only you could differentiate open instances of the same device from each other, so that mixing would just be implied, and "just work"... if only the sound device were a *cloning device*. 8-). > 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. ??? You are suggesting two devices? That's quite interesting. I suppose it's possible, if you absolutely insist on it. I guess pushing the complexity from a relatively trivial device driver operation into a much more complex file system operation would work. IMO, though, it would not really be a good idea. It's like laying carpet, and leaving a bubble in it. You can chase it all around your living room, but the bubble is going to be *somewhere*. > 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. I'm not *talking* about multiple processes. For example, I have three mice on the machine from which I am currently typing: 1) A 3 button USB two axis optical mouse 2) A 2 buttom "glidepoint" two axis touchpad 3) A 1 button one axis "jogdial" All of these are devices to mux into a single program, the X server, and from there, into the Window Manager, so that I can make them behave as they do under Windows (e.g. my "jogdial" input needs to be routed to a popup utility that can launch programs). While my #1 and #2 need to be treated as synonyms (including treating the third button on the optical mouse the same as a chord of button 1&2 on the touchpad). I'd rather not have to go outside the normal operation of my X server input manager, in order to be able to achieve this. I'd rather just set it up so that the jogdial were reported as button events. > 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. You're high. What happens when I have two programs, and one of them doesn't know to make it's write of escape sequences atomic, because it's not expecting a second program to be sending escape sequences to select and deselect output to the AUX port on the terminal?!? Someone, somewhere has to keep the interference management finite state automaton, so that the single real serial device driver underneath is able to prevent data corruption to the printer or the screen for simultaneously operating programs. Yeah, FreeBSD doesn't do this today, but then it's not a commercial grade OS that has to be able to deal with, for example, running the terminals and the little receipt printer at a video store. > 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... No, I think this is what they wanted. I think that you can't say that they aren't building a clone of the pty code on Linux or SVR4, so that commercial programs run under the ABI will run properly under FreeBSD. So, no matter what, whether you think "it's the FreeBSD way" or not, it needs to be possible to support it. -- 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?3D06430E.D58FF87A>