Date: Wed, 12 Jun 2002 00:07:03 -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: <3D06F317.C2FFB40F@mindspring.com> References: <20020612083231.B35453-100000@beagle.fokus.gmd.de>
next in thread | previous in thread | raw e-mail | index | archive | help
Harti Brandt wrote: > You just don't know what you are talking about. This is exactly the > difference between the current Linux sound (1 device) and FreeBSD (1 > device/channel). In FreeBSD I can use N channels with different audio > formats and speeds, in Linux I'm stuck to using all the channels with the > same format. Try to write a conferencing tool, that has to work in a > heterogenous environment. That's not an artifact of it being a "single device"; with a context per open instance, it's either an artifact of inability to manipulate the instance data via ioctl(), or the failure of the user software to open the underlying device more than once, so that it has different instances to work with to achieve your goal. From an application point of view, the only difference is whether you have to guess names to get at the extra channels, or just open the same name more than once. In FreeBSD, the device names are only a proxy for the differences in major/minor number pairs (as are all devices). The differences in minor numbers are themselves just a proxy for instance information. Where the instance comes from is really irrelevent, to the application, so long as it gets (1) one instance per fd, and (2) more than one fd. The only *real* difference I can see here is that programs built to run against the Linux ABI won't behave correctly when run on FreeBSD under FreeBSD's Linux ABI implementation. > Yes. And to open a file on disk I open /dev/da0s1a and then issue an ioctl > to get to the file (and a new device entry) and every disk driver > implements the file system. Every sound device writer writes all the > mixing and code conversion code into his driver... Just idiotic... This is a reductio ad absurdum argument. It leaves no room for the idea that there exist inappropriate applications of technology. Just because a hammer works once, does not make every problem a nail. If you looked at the recent followup by the original poster, you will see that what he has, in fact, is a device driver that really needs to permit him formatted access to a bus. A bus is an application for which cloning is a *really* good model to use for devices. > Mixing and code conversion is something you should do above the device > layer, just as you do TCP not in the network driver. What's the the API > that the user program sees from this generic layer is just a matter of > taste - cloning pseudo devices would be just fine. I understand your point, but I think you have chosen a particularly bad example. The problem with this example is that there have been a very large number of times where I have thought it would be useful to be able to have the TCP connection associated with the active browser window (the one in the foreground and/or the one that is selected as the active window -- having the input focus) have a higher priority than the other TCP connections associated with other windows belonging to the same browser application. It would be incredibly useful if I could start a number of downloads that I know will take a long time, and then continue browsing, and have the application "just do what I want", by prioritizing traffic based on which window has my personal attention. I know that the typical answer to this is "rewrite the Internet to support QOS", but this isn't really an answer. Without a negotiated QOS, I can still control the number of buffers in use on the peer which provides my connectivity by diddling with the window size advertisements my machine sends to the peer router, so that the peer router buffers don't become saturated with data for the file transfer sessions, and therefore my interactive response does not suffer (the current AltQ integration into FreeBSD does *NOT* use this technique, and so can not make the same guarantees, particularly when there is an inpedence mismatch between the ISP link and the "last mile" link to my machine, with my "last mile" being significantly slower). Julian Elisher built something similar to this into the Whistle InterJet, near the end, but it was only useful for trafic shaping, not explicit QOS control by the application. I guess my point to this whole example is that where you draw the line dictates the properties of the resulting system, and the more control you give to the application, the better, in most cases. In a perfect world, I think this would include TCP. -- 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?3D06F317.C2FFB40F>