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/