lkml.org 
[lkml]   [2002]   [Jan]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [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/

    \
     
     \ /
      Last update: 2005-03-22 13:15    [W:0.027 / U:0.716 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site