Date: Tue, 05 Jan 1999 23:10:30 +0800 From: Peter Wemm <peter@netplex.com.au> To: freebsd-arch@FreeBSD.ORG Subject: Re: DEVFS, the time has come... Message-ID: <199901051510.XAA21446@spinner.netplex.com.au> In-Reply-To: Your message of "Tue, 05 Jan 1999 14:47:20 %2B0100." <19624.915544040@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199901051510.XAA21446>