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]

Date:	Fri, 26 Oct 2007 17:55:47 +0200
From:	Kay Sievers <kay.sievers@...y.org>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Nick Piggin <nickpiggin@...oo.com.au>,
	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,
	Trond Myklebust <trond.myklebust@....uio.no>,
	Miklos Szeredi <miklos@...redi.hu>
Subject: Re: per BDI dirty limit (was Re: -mm merge plans for 2.6.24)


On Fri, 2007-10-26 at 17:33 +0200, Peter Zijlstra wrote:
> On Fri, 2007-10-26 at 17:33 +0200, Kay Sievers wrote:
> > On Fri, 2007-10-26 at 17:22 +0200, Peter Zijlstra wrote:
> > > On Fri, 2007-10-26 at 17:10 +0200, Kay Sievers wrote:
> > > > On Fri, 2007-10-26 at 16:48 +0200, Peter Zijlstra wrote:
> > > > 
> > > > > I appreciate the sysfs people their opinion that /sys/bdi/ might not be the
> > > > > best from their POV, however I'm not seeing where to hook the BDI object from
> > > > > so that it all makes sense, a few of the things are currently not exposed in
> > > > > sysfs at all, like the NFS and FUSE things.
> > > > 
> > > > What happended to the idea to create a "bdi" class, and have the
> > > > existing devices as parents, and for stuff that is not (not now, or
> > > > never) in sysfs, no parent is set.
> > > 
> > > Must have forgotten about that, mainly because I'm not sure I fully
> > > understand it.
> > > 
> > > So we create a class,
> > 
> > Yes.
> > 
> > > create these objects,
> > 
> > Yes, "struct device" objects, assigned to the "bdi" class. (Don't use
> > class_device, that will be removed soon.)
> > 
> > > which are all called bdi
> > 
> > Probably not. You can name it how you want, you can inherit the name of
> > the parent, or prefix it with whatever fits, they just need to be
> > unique. Things like the "fuse-%llu" name would work just fine. I guess
> > you already solved that problem in the debugfs directory.
> > 
> > > and have children with these attributes in it.
> > 
> > The attributes would just be files in the device object.
> > 
> > > Now, I supposed there is a directory that lists all unparented thingies,
> > > how do I locate the one that matches my nfs mount?
> > 
> > You look for the name (prefix), try: "ls /sys/class/sound/", it's the
> > same model all over the place.
> 
> Ok, will try that. Is there a 'simple uncluttered' example I could look
> at to copy from?

drivers/firmware/dmi-id.c

It has only a single device created in the init routine, but it shows
what to do with the class.

Until the block subsystem is converted from using raw kobjects to
devices, you need to set the parent kobject of the bdi device to the
blockdev:
  bdidev->dev.kobj.parent = &disk->kobj

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/