Messages in this thread | | | Date | Tue, 8 Jan 2002 22:41:24 -0700 | From | Richard Gooch <> | Subject | Re: [PATCH] DevFS support for /dev/cpu/X/(cpuid|msr) |
| |
H. Peter Anvin writes: > Richard Gooch wrote: > > >>> > >>So you chown an entry, then a module is unloaded and reloaded, now > >>what happens? > >> > >>It's the old "virtual filesystem which really wants persistence" > >>issue again... > >> > > > > Works beautifully with devfs+devfsd :-) > > > > Permissions get saved elsewhere in the namespace (perhaps even to the > > underlying /dev) as you chown(2)/chmod(2)/mknod(2), and are restored > > when entries are (re)created and/or at startup. > > > > My /dev has persistence behaviour which looks like a FS with backing > > store. > > Yes, after quite a few years it finally got in there. This is a Good > Thing[TM]. Now apply the same problem to /proc.
Actually, the COPY action has been available since APR-2000 :-)
But as for applying this to /proc, that's a good point. My current plans are to write v2.0 of the devfs core, which will use the dcache to maintain the devfs tree structure, rather than having my own code to do it. That should result in a significant reduction in code side, and maybe finally people won't hate the idea so much.
So then, one approach would be to have control files where you want to have permissions persistence placed in devfs. Of course, for consistency, you'd want all control files under devfs. A /dev/sys hierarchy perhaps.
Another idea is to turn devfs into some kind of "kernfs", and have one instance for /dev, another for /proc/sys (or /system if you like), and run an instance of devfsd (renamed to "kernfsd" perhaps) for each of these instances.
Of course, it depends on whether people *want* permissions persistence for /proc/sys. Is there much call for this?
Regards,
Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |