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

[Kay Sievers]

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.

Kay

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