Date: Tue, 05 Jan 1999 14:47:20 +0100 From: Poul-Henning Kamp <phk@critter.freebsd.dk> To: freebsd-arch@FreeBSD.ORG Subject: Re: DEVFS, the time has come... Message-ID: <19624.915544040@critter.freebsd.dk> In-Reply-To: Your message of "Sun, 03 Jan 1999 12:33:32 PST." <199901032033.MAA07162@dingo.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Well, summary #2:
1. Nobody against DEVFS as standard so far.
2. All talk of persistence implemented in the kernel has stopped.
Cool, that is much further than -core has managed to get in 2.5 years.
The next thing to tackle is the "devd": what it does.
(NB: NOT HOW IT DOES IT, I will urge the moderator to try to stay
close to this policy for this discussion, thankyou!)
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.
So, lets brainstorm the "devd" concept a bit, where does it come into
play ?
* Device node permission policy implementation ("I want disks to be 640
root/operator")
* Device node permission persistence ("He did a ``chmod 777 /dev/rwd0a'',
give it to him after every reboot if persistence is enabled")
* Device presence handling ("Ahh, A CD in the drive, lets see:
mount that under /cd2/386bsd-0.0" and "umount -f /cd2/386bsd-0.0")
This third point needs a good amount of thought from us all, and is
probably the only one we haven't already resolved by and large:
Some of the obvious things you can do with this is:
* Download microcode
* mount/unmount disks/cd/zip/whathaveyou
* start getty or ppp processes on serial ports (pccard modems!)
* handle "configuration sets", ie "notebook docked" vs "notebook undocked"
vs "notebook with pcmcia ethernet at customer #1 network" and so on.
Some of this is as trivial as "locate the right command for this device
and execute it" no sweat.
Trouble starts with PnP, Pccard, USB and cardbus.
PnP for instance will send a event before undocking is physically
allowed (they learned that much from the PCMCIA mistake :-).
It sounds to me like this is a "devd" job. Mostly because I hate
the idea of having too many daemons hanging around, but more probably
because so many of the issues are in the same corner of the field
that if we don't integrate these things, we will have to make them
talk together anyway to avoid flattened toes.
Does anybody see a way to meta-ize devd (as in "inetd") to avoid
having all the code for the various ugly standards loaded by default,
but still retain a good integrated view of things ? (people without
detailed knowledge of PnP, PCCARD, USB need not bother with an answer).
--
Poul-Henning Kamp FreeBSD coreteam member
phk@FreeBSD.ORG "Real hackers run -current on their laptop."
FreeBSD -- It will take a long time before progress goes too far!
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?19624.915544040>