[lkml]   [2007]   [Oct]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: sysfs sys/kernel/ namespace (was Re: [PATCH 0/2] add new notifier function ,take2)
    On Wednesday 24 October 2007 21:12, Kay Sievers wrote:
    > On 10/24/07, Nick Piggin <> wrote:
    > > On Tuesday 23 October 2007 10:55, Takenori Nagano wrote:
    > > > Nick Piggin wrote:
    > > > > One thing I'd suggest is not to use debugfs, if it is going to
    > > > > be a useful end-user feature.
    > > >
    > > > Is /sys/kernel/notifier_name/ an appropriate place?
    > >
    > > I'm curious about the /sys/kernel/ namespace. I had presumed that
    > > it is intended to replace /proc/sys/ basically with the same
    > > functionality.
    > It was intended to be something like /proc/sys/kernel/ only.

    Really? So you'd be happy to have a /sys/dev /sys/fs /sys/kernel
    /sys/net /sys/vm etc? "kernel" to me shouldn't really imply the
    stuff under the kernel/ source directory or other random stuff
    that doesn't fit into another directory, but attributes that are
    directly related to the kernel software (rather than directly
    associated with any device).

    > > I _assume_ these are system software stats and
    > > tunables that are not exactly linked to device drivers (OTOH,
    > > where do you draw the line? eg. Would filesystems go here?
    > We already have /sys/fs/ ?
    > > Core network algorithm tunables might, but per interface ones probably
    > > not...).
    > We will merge the nonsense of "block/", "class/" and "bus/" to one
    > "subsystem". The block, class, bus directories will only be kept as
    > symlinks for compatibility. Then every subsystem has a directory like:
    > /sys/subsystem/block/, /sys/subsystem/net/ and the devices of the
    > subsystem are in a devices/ directory below that. Just like the
    > /sys/bus/< name>/devices/ layout looks today. All subsystem-global
    > tunables can go below the /sys/subsystem/<name>/ directory, without
    > clashing with the list of devices or anything else.

    Makes sense.

    > > I don't know. Is there guidelines for sysfs (and procfs for that
    > > matter)? Is anyone maintaining it (not the infrastructure, but
    > > the actual content)?
    > Unfortunately, there was never really a guideline.
    > > It's kind of ironic that /proc/sys/ looks like one of the best
    > > organised directories in proc, while /sys/kernel seems to be in
    > > danger of becoming a mess: it has kexec and uevent files in the
    > > base directory, rather than in subdirectories...
    > True, just looking at it now, people do crazy things like:
    > /sys/kernel/notes, which is a file with binary content, and a name
    > nobody will ever be able to guess what it is good for. That should
    > definitely go into a section/ directory. Also the VM stuff there
    > should probably move to a /sys/vm/ directory along with the weird
    > placed top-level /sys/slab/.

    Top level directory IMO should be kept as sparse as possible. If
    you agree to /sys/mm for example, that's fine, but then slab should
    go under that. (I'd prefer all to go underneath /sys/kernel, but...).

    It would be nice to get a sysfs content maintainer or two. Just
    having new additions occasionally reviewed along with the rest of
    a patch, by random people, doesn't really aid consistency. Would it
    be much trouble to ask that _all_ additions to sysfs be accompanied
    by notification to this maintainer, along with a few line description?
    (then merge would require SOB from said maintainer).

    For that matter, this should be the case for *all* userspace API
    changes (
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2007-10-25 04:41    [W:0.025 / U:4.648 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site