From owner-freebsd-arch Tue Jan 5 07:23:21 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA26247 for freebsd-arch-outgoing; Tue, 5 Jan 1999 07:23:21 -0800 (PST) (envelope-from owner-freebsd-arch@FreeBSD.ORG) Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA26242 for ; Tue, 5 Jan 1999 07:23:16 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.1a/8.9.1) with ESMTP id QAA17195 for ; Tue, 5 Jan 1999 16:22:43 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id QAA15570 for freebsd-arch@freebsd.org; Tue, 5 Jan 1999 16:22:42 +0100 (MET) Received: from spinner.netplex.com.au (spinner.netplex.com.au [202.12.86.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA25039 for ; Tue, 5 Jan 1999 07:11:02 -0800 (PST) (envelope-from peter@netplex.com.au) Received: from spinner.netplex.com.au (peter@localhost [127.0.0.1]) by spinner.netplex.com.au (8.9.1/8.9.1/Netplex) with ESMTP id XAA21446 for ; Tue, 5 Jan 1999 23:10:31 +0800 (WST) (envelope-from peter@spinner.netplex.com.au) Message-Id: <199901051510.XAA21446@spinner.netplex.com.au> X-Mailer: exmh version 2.0.2 2/24/98 To: freebsd-arch@FreeBSD.ORG Subject: Re: DEVFS, the time has come... In-reply-to: Your message of "Tue, 05 Jan 1999 14:47:20 +0100." <19624.915544040@critter.freebsd.dk> Date: Tue, 05 Jan 1999 23:10:30 +0800 From: Peter Wemm Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Poul-Henning Kamp wrote: [..] > Some thinking points: > > * "devd" must be optional, for embedded applications where space is > tight we don't want to force people to run it. It could also > quickly become a problem for machines with many chroot jails if > they needed a devd for each, so the "/etc/dev.rc" mode of config > must be an option. > > * "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. > I am against implementing them in the kernel because it should not > be needed to change the kernel to introduce a new class, and it isn't > a job for the kernel anyway in my eyes. For devd to be optional, then the kernel needs to help a little so that /etc/rc can do enough to result in a sane and workable system. Otherwise, devd isn't going to have a clue what a "blurf" device is when it gets loaded or appears on a dynamic bus. 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 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. An additional concern.. There are two types of persistance.. The first is persistance across reboot (IMHO, this is not needed with a decent backing infrastructure). The second is persistance across add/remove of nodes during the time the machine is up (eg: usb devices, partition/ slices that change on removable media or as a result of partitioning). The second would be sort-of covered by devd, as long as the config file was edited in advance. Cheers, -Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message