On Jan 8, 11:56am, Perry E. Metzger wrote:
> Subject: Re: Share common code/data across ports?
>
> 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
> > else.
> >
> > 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.

Well, how about putting the data needed to create the devices in devfs as
opposed to the devices themselves, and then modifying MAKEDEV to use this data.
That way the sysadmin can keep control of things by modifying MAKEDEV (easy
enough to add some chmods to MAKEDEV.local) and any Solaris-lovers out there
can invoke MAKEDEV from rc when given a -r flag.

Cheers

Rob Black