Re: DEVFSv50 and /dev/fb? (or /dev/fb/? ???)
Richard Gooch (Richard.Gooch@atnf.CSIRO.AU)
Fri, 7 Aug 1998 09:39:08 +1000
Jurgen Botz writes:
> Richard Gooch wrote:
> > Theodore Y. Ts'o writes:
> > > policy and naming issues in the kernel. (2) The hacks that you need so
> > > that you can save the user/group ownership and permissions are too ugly
> > > to contemplate. (3) Device inodes really do need major and minor device
> >[...]
> > 2) which hacks are these? You mean using tar to save and restore the
> > permissions? Would you prefer a C programme (something I'm
> > contemplating doing)
>
> As stated previously I like DEVFS, but this is one thing I'm not too
> crazy about either... something about this method of saving state at
> shutdown time seems un-Unixish to me.
>
> What I'd rather do is to simply keep a file that lists those devices
> that I want to have other than default permissions and have them set
> from this file at boot time. To change the permissions of a device
> permanently, edit this file and run a script that "applies" it. The
> config file (/dev/dev.conf or something) might be able to use regexes
> to match devices.
>
> In either case to be safe changing permissions is a two-step process,
> since you have to execute the "save" procedure manually now after
> changing permissions to be sure they stay changed if the system
> crashes (oh, yeah, I know Linux /almost/ never crashes, but for a
> sysadmin of mission-critical systems almost isn't good enough ;-).
You can easily run a cron job to save the permissions regularly.
> Anyhow, this seems like a relatively minor point.
Indeed. The devfs concept is a separate issue from how the persistence
is implemented. Like I've said before, I can implement real disc-based
persistence in the FS if needed.
Regards,
Richard....
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html