[lkml]   [2007]   [Oct]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: per BDI dirty limit (was Re: -mm merge plans for 2.6.24)
    On 10/2/07, Peter Zijlstra <> wrote:
    > On Tue, 2007-10-02 at 13:21 +0200, Kay Sievers wrote:
    > > On 10/2/07, Peter Zijlstra <> wrote:
    > > > On Tue, 2007-10-02 at 12:31 +0200, Kay Sievers wrote:
    > > >
    > > > > What would be the point in another top-level tree for device
    > > > > information? All devices you are exporting information for, are
    > > > > already in the sysfs tree, right?
    > > >
    > > > Never did find NFS mounts/servers/superblocks or whatever constitutes a
    > > > BDI for NFS in there. Same goes for all other networked filesystems for
    > > > that matter.
    > >
    > > How about adding this information to the tree then, instead of
    > > creating a new top-level hack, just because something that you think
    > > you need doesn't exist.
    > So you suggest adding all the various network filesystems in there
    > (where?), and adding the concept of a BDI, and ensuring all are properly
    > linked together - somehow. Feel free to do so.

    No, I propose to add only sane new userspace interfaces. That you miss
    infrastructure to use, should never be the reason to add conceptually
    broken new interfaces. A new device related top-level directory in
    /sys is not going to happen. Better don't add new stuff, if you can't
    do it right.

    > > You called sysfs a mess, seems you work on that topic too. :)
    > I called the in-kernel API to create sysfs files a mess. Not that I have
    > another opinion on the content of /sys though, always takes to damn long
    > to find anything in there.

    Sure, it's a mess, we are trying to clean that up, it's hard, and
    therefore we can not accept stuff like you propose, that makes it even

    Use debugfs, if you can't add a sane interface. There are no rules,
    you can do whatever you want there. If over time the stuff you need
    gets added, you can always switch over.

    Or add an attribute group to the existing devices, and leave the ones
    out, which are not in sysfs right now, until they are added.

    Or use a device class and use the existing devices as parents. If you
    don't have a parent, they will show up in "virtual" until someone adds
    the right parent devices. (If you are going to do this, make sure
    nothing depends on a device being "virtual", it must be allowed to
    re-parent these device with any future kernel release.)

    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-02 16:41    [W:0.022 / U:1.640 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site