Date: Tue, 5 Jan 1999 19:43:01 +0200 (EET) From: Narvi <narvi@haldjas.folklore.ee> To: freebsd-arch@FreeBSD.ORG Subject: Re: DEVFS, the time has come... Message-ID: <Pine.BSF.3.96.990105192226.5112V-100000@haldjas.folklore.ee> In-Reply-To: <199901051510.XAA21446@spinner.netplex.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 5 Jan 1999, Peter Wemm wrote: > Poul-Henning Kamp wrote: > [..] >> Some thinking points: >> [snip] >> * "device classes", are probably a good idea, although I have a >> hard time finding more classes than "disk" and "tty" and >> "console associated", where the latter covers mice, sound, >> keyboards, cameras and so on. While mice, sound and keyboard may indeed be related to the console, I fail to find any reason why a camera should be "console associated". While video conferencing and video editing certainly are interesting and console associated, these are but some of the ways cameras get used. Cameras are much rather class "data acquisition" or class misc rather than class "console associated". Device classes may be useful, but creating a set of device classes that both covers most devices, is meaningful and extensible is not trivial. [snip] > Other important classes are that spring to mind: cua (quite different to > tty), "tape" (different to disk). There are some others that are not so > clear, the floppy and cdrom being one. Are they a "disk" or "console > related"? It certainly could be important since if the system sees Leaving floppy aside, a cd-rom can be both class "disk" and class "console associated", indeed, there could be cd-roms in both "classes" present in the system at the same time. A cd-rom device in a cd-rom tower for which the system is no more than the interface to the network and cache is definitely class "disk". The cd-rom in the desktop computer that has most of the time an audio cd in it and occasionally a data cd or in which data cd-roms get changed often is "console associated", especially if the machine is "public". How will multi-class devices be treated? Or should we have class "cd-rom"? > partitions/slices on it, then it has to know what to call them. On a > system without devd running, one would have to > chmod -R 666 /dev/fd* /dev/rfd* > every time the floppy was changed. However, being able to set the modes via > a sysctl would solve that without needing devd. I know the users would > have it shot if that was the case. Implementing class support in the kernel > should be almost trivial compared to the devfs task itself. I think that a > driver should be able to name it's class (creating it if it doesn't exist > yet), just like the VFS's choose their own name. > Anything single-purpose can know it's class. Everything that can be used in multiple classes must be able to migrate classes, possibly instance at a time. Will root be able to tell the device to leave behind it's silly prejudices and start behaving like it should and joining another device class? Will it be able to tell some instances of the device to join another class? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.990105192226.5112V-100000>