Re: Suggested dual human/binary interface for proc/devfs

From: Marcus Sundberg (erammsu@kieraypc01.p.y.ki.era.ericsson.se)
Date: Fri Apr 14 2000 - 04:33:38 EST


Horst von Brand <vonbrand@sleipnir.valparaiso.cl> writes:

> Richard Gooch <rgooch@ras.ucalgary.ca> said:
> > My, you have a selective memory. I've proposed more than one workable
> > solution to this:
> >
> > - tar/untar (it may not appeal to you, and it doesn't appeal to me
> > that much either, but it will do the job)
>
> It is horrible, and breaks in any case where the machine isn't shut down
> cleanly. No dice.
>
> > - set permissions in /etc/devfsd.conf, edit to change
>
> Doesn't work at all with chmod/chown. No dice.
>
> > - configure devfsd to automatically save/restore (possible *right
> > now*, although requires configuring, I could provide a canned
> > solution to make it easier)
>
> How would this work over crashes?

>From time to time I find this debate very strange.
The *last* thing I want on a crash is completely random device
permissions and ownerships to persist through the reboot.

One of the things I like best with devfs is that I can configure
the device permissions in /etc/devfsd.conf (the few I want to
deviate from the defaults), and know that I will always get these
correct permissions on every boot, even if I had to do SysRq-u,
SysRq-s, SysRq-b.

Changing the bootup permissions on device nodes should be quite rare
in most systems, and doing it in a single file seems much more clean
than doing it in a directory tree where permissions on things like
TTYs are constantly changing around you.

The other thing I like about devfs is that you can have the root
filesystem read-only without any fuss, which also helps to ensure
consistency across crashes.

//Martcus

-- 
Signature under construction, please come back later.

- 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.tux.org/lkml/



This archive was generated by hypermail 2b29 : Sat Apr 15 2000 - 21:00:24 EST