[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090626132940.GR23611@kernel.dk>
Date: Fri, 26 Jun 2009 15:29:40 +0200
From: Jens Axboe <jens.axboe@...cle.com>
To: NeilBrown <neilb@...e.de>
Cc: "Martin K. Petersen" <martin.petersen@...cle.com>,
Mike Snitzer <snitzer@...hat.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Alasdair G Kergon <agk@...hat.com>,
linux-scsi@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-raid@...r.kernel.org, linux-ide@...r.kernel.org,
linux-fsdevel@...r.kernel.org,
device-mapper development <dm-devel@...hat.com>
Subject: Re: [dm-devel] REQUEST for new 'topology' metrics to be moved out
of the 'queue' sysfs directory.
On Fri, Jun 26 2009, NeilBrown wrote:
> On Fri, June 26, 2009 10:50 pm, Jens Axboe wrote:
> > On Fri, Jun 26 2009, Neil Brown wrote:
> >> Every block device has a 'gendisk' (aka generic disk).
> >> Every block device also (currently) has a request_queue.
> >
> > I don't know why you keep saying currently. It has always had a queue,
> > and I don't see a good reason why that should change for "special" block
> > devices like md/dm/loop/whatnot.
>
> I say "currently" because I'm planning to create patches to make it
> optional, and I want to get you used to the idea :-)
>
> And md/dm/loop/whatnot are not "special" block devices, any more than
> scsi/ide are "special" block devices. They are all just block devices.
> They use different mechanisms, but each is just as valid as the other.
That was why I put it in quotes, they are just regular devices.
> The current code makes 'struct request' based block devices in to
> first-class citizens, and all the rest are second class (having to
> tag our data structures on ->queue data and/or ->private_data).
?? How is that different from devices, the ones you refer to as
first-class citizens? They too store device private data in eg
->queue_data.
> I just want all block devices to be equal.
There's no such thing as first or second class block devices. The fact
that drivers using ->make_request_fn directly do not utilize the full
scope of the queue isn't a very interesting fact, imho.
--
Jens Axboe
--
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