Subject: Re: Share common code/data across ports?
To: der Mouse <email@example.com>
From: Perry E. Metzger <firstname.lastname@example.org>
Date: 01/08/1997 11:56:51
Actually, it is possible to combine a devfs with some sort of
configuration file so that all the changes you list survive across
reboots, but I agree with you that its not clear why you want devfs in
the first place...
der Mouse writes:
> > Another way (which I prefer) is to eliminate MAKEDEV and let the
> > kernel make the device nodes for us, possibly in a special filesystem
> > for that purpose, automatically mounted on /dev/.
> I really really dislike this.
> Why? Because it means the user-level device names are wired into the
> kernel. Because it means I can't "ln -s kd ttykd" to fix "ps atkd" on
> the sun3 port as a stopgap measure until ps is fixed right. Because it
> means I can't "chmod 666 /dev/*sd4*" so that anybody can access the zip
> drive. Because it means I can't "chgrp backup /dev/rsd*" so that I can
> have a group dedicated to backups to read the disks, instead of having
> to use the provided operator group which owns ghod-only-knows what
> Or if devfs does support the above, it means the results won't survive
> the next reboot.
> To me as a sysadmin, this is unacceptable. devfs may be useful,
> perhaps; I'd actually prefer to make it part of kernfs (/kern/dev, say)
> and then if you really want to use it as your /dev, symlink /dev to
> /kern/dev (and create a few things in /kern/dev on the root filesystem,
> to be hidden by the kernfs mount, enough things for it to come up far
> enough to mount kernfs). Personally, I'd create a database of things
> in devfs I don't want in /dev and things I want in /dev even though
> devfs doesn't have them, then check /dev against devfs and this list at
> boot time, warning of differences but not touching anything.
> der Mouse
> 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B