lkml.org 
[lkml]   [1999]   [Oct]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectOther $0.02 on devfs permission persistance
Date

I've been thinking about this whole devfs thing.. I read through most of the
FAQ and read almost all of that big flame war (from which I didn't learn much).
I'm not a kernel hacker, so I'm a fish-out-of-water in this forum. But none the
less, I thought I'd throw my one idea into the pit.

The devfs FAQ seems to indicate in the section "Persistence of
ownership/permissions across reboots" that the rc.devfs script is required to
make permission modifications made through chmod(2) stick. It also seems to say
that permissions _should_ be modified using the configuration file, which gives
the user more control and is naturally persistent over reboots. But if the
permissions are modified with chmod(2) then rc.devfs is required for
persistence. Is this true?

If so that seems kind of annoying. I'd prefer that permission modifications
made with chmod(2) stick even if the system crashes and the background
user-space daemon was never started. It seems that the problem is having devfs
store _any_ information in memory that we want to eventually become persistent
and stored to disk (either by some script on shutdown or the devfsd) .

Seems to me that the solution could be to mount devfs off of some block device
that would provide a place for this information to be directly stored by devfs.
Perhaps this could be done with a loopback device and the underlying format be
in text.

Does this make any sense at all?

- David Harris
Principal Engineer, DRH Internet Services



-
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/

\
 
 \ /
  Last update: 2005-03-22 13:54    [W:0.047 / U:0.172 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site