[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1194013979.2440.20.camel@lov.site>
Date: Fri, 02 Nov 2007 15:32:59 +0100
From: Kay Sievers <kay.sievers@...y.org>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Greg KH <greg@...ah.com>, 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>,
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-11-02 at 15:17 +0100, Peter Zijlstra wrote:
> One more question,
>
> I currently prefix the names with "bdi-", is that needed?
Not really.
> That is, if I give the bdi object a parent, how will it look?
> Would a bdi device with name "sda" with a block device called "sda" as
> parent look like: /sys/block/sda/sda? Or would if be
> called /sys/block/sda/bdi:sda or just /sys/block/sda/bdi?
The class devices as childs get their own subdirectory at the parent. So
it would be /sys/block/sda/bdi/sda
It's currently only implemented for class devices which get a bus device
as a parent, but that will be for all parents, so that we prevent
clashing names if devices from multiple subsystems get the same parent.
See here for netdevs there is a "net" "glue directory":
$ ls -l /sys/class/net/eth0
/sys/class/net/eth0 -> ../../devices/pci0000:00/0000:00:1c.0/0000:02:00.0/net/eth0
We needed this, because people complained that they can't name their
netif "irq", because there is already an attribute at the parent with
that name. :)
When we get the "block as devices" patch merged, we can do the proper
parent logic for bdi, and I'll add the same logic as we have for bus
device parents today.
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/
Powered by blists - more mailing lists