Messages in this thread | | | From | "David Harris" <> | Subject | Other $0.02 on devfs permission persistance | Date | Mon, 11 Oct 1999 11:58:48 -0400 |
| |
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/
| |