linux-kernel - Re: per BDI dirty limit (was Re: -mm merge plans for 2.6.24)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <3ae72650710020738g7c80135au8618cf2dd2850eb@mail.gmail.com>
Date:	Tue, 2 Oct 2007 16:38:24 +0200
From:	"Kay Sievers" <kay.sievers@...y.org>
To:	"Peter Zijlstra" <peterz@...radead.org>
Cc:	"Andrew Morton" <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, "Jens Axboe" <jens.axboe@...cle.com>,
	"Fengguang Wu" <fengguang.wu@...il.com>, greg@...ah.com
Subject: Re: per BDI dirty limit (was Re: -mm merge plans for 2.6.24)

On 10/2/07, Peter Zijlstra <peterz@...radead.org> wrote:
> On Tue, 2007-10-02 at 13:21 +0200, Kay Sievers wrote:
> > On 10/2/07, Peter Zijlstra <peterz@...radead.org> 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
harder.

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.)

Thanks,
Kay
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/