This patch makes good on a threat that I posted yesterday
to move struct io_restrictions from <linux/device-mapper.h> to
<linux/blkdev.h>, eliminating duplication of a list of fields in
struct request_queue.
This change makes it easier to manipulate these parameters as
a group, which should allow simplification of a number of drivers that
currently manipulate a subset of these parameters. I believe it will
enable a number of clean-ups, but I have deliberately not make most of
those clean-ups in this version, because I would like to first get
this infrastructure adjustment done as reliably as possible, hopefully
for 2.5.46.
By the way, eventually, this change should also make it easier
to lift the mergability tests out of the block layer and make them
work on gather-scatter DMA in general.
I am running this patch now. Well, actually, the ll_rw_blk.c
that I'm including here is different from the one that I use, because
I have a bunch of other changes in the version of that file that I
actually use, but the version in this patch compiles without warnings
and the changes are trivial.
Jens, can I persuade you to integrate this change?
--
Adam J. Richter __ ______________ 575 Oroville Road
[email protected] \ / Milpitas, California 95035
+1 408 309-6081 | g g d r a s i l United States of America
"Free Software For The Rest Of Us."
On Sat, Nov 02 2002, Adam J. Richter wrote:
> This patch makes good on a threat that I posted yesterday
> to move struct io_restrictions from <linux/device-mapper.h> to
> <linux/blkdev.h>, eliminating duplication of a list of fields in
> struct request_queue.
Adam, I generally think the patch is a good idea. I also think it's a
very stupid time to start messing with stuff that is basically trivial
but still touches lost of stuff.
Please leave it alone for a few weeks.
> Jens, can I persuade you to integrate this change?
In due time, yes.
--
Jens Axboe
Jens Axboe wrote:
>On Sat, Nov 02 2002, Adam J. Richter wrote:
>> This patch makes good on a threat that I posted yesterday
>> to move struct io_restrictions from <linux/device-mapper.h> to
>> <linux/blkdev.h>, eliminating duplication of a list of fields in
>> struct request_queue.
>Adam, I generally think the patch is a good idea. I also think it's a
>very stupid time to start messing with stuff that is basically trivial
>but still touches lost of stuff.
It's pretty much simple string substitution and it doesn't
touch that many files, but OK.
>Please leave it alone for a few weeks.
>> Jens, can I persuade you to integrate this change?
>In due time, yes.
Great. The only thing I was going to do that might depend
on this patch is try to port /dev/loop to device mapper, and I may
be able to eliminate the affected code anyhow.
I've checked in the change and will continue running it in the
meantime. Unless I hear otherwise or run into a problem with this
patch, I'll plan to resubmit it around November 24.
Adam J. Richter __ ______________ 575 Oroville Road
[email protected] \ / Milpitas, California 95035
+1 408 309-6081 | g g d r a s i l United States of America
"Free Software For The Rest Of Us."
On Sun, Nov 03, 2002 at 12:48:30AM -0800, Adam J. Richter wrote:
> Great. The only thing I was going to do that might depend
> on this patch is try to port /dev/loop to device mapper, and I may
> be able to eliminate the affected code anyhow.
This makes me uneasy, do you mean you want to:
i) make a 'loop' target, if so why ?
ii) or that you want to rewrite loop so that it sits on top of dm -
ie. you create a set of linear mappings that correspond to the
file ? This would only be sensible if there is significant
simplification/reduction of the loop code, and probably would
never work because of tail packing.
I'm not keen on either of these ideas.
- Joe
>On Sun, Nov 03, 2002 at 12:48:30AM -0800, Adam J. Richter wrote:
>> Great. The only thing I was going to do that might depend
>> on this patch is try to port /dev/loop to device mapper, and I may
>> be able to eliminate the affected code anyhow.
>This makes me uneasy, do you mean you want to:
>i) make a 'loop' target, if so why ?
I believe I can eliminate some block device initialization
code and also eliminate some ioctls that allow for a lot of number
configured states for a loop device and bloat loop.c with some
features nobody uses (for example, there is an unused facility to
"name" each loop device). I would like to invent as little new API as
possible. Also, of much less importance, adopting this change would
relinquish a major device number.
I was going to have the map function always return 0 (i.e., it
will submit the IO itself). Given device-mapper with linear mapping,
I don't think anyone will need to use loop just to map a device to a
device with no data transformation, so there is no need for loop
optimize for that case.
If you want to point out specific technical problems with this
or have other advice, great. Otherwise, I expect that just trying to
implement it will either show me some problem with it or will result
in a patch that should clarify what I am talking about for you.
By the way, one change to DM that might be useful for other
targets as well as loop.c would be to move the map function from
target_type to dm_target. This can potentially be used to eliminate
some branches in the IO path based on configuration options that were
passed to the constructor function. For loop.c, I am thinking of
file backed versus device backed. I could also imagine raid schemes
that might optimize their map functions differently for different
segment sizes.
Adam J. Richter __ ______________ 575 Oroville Road
[email protected] \ / Milpitas, California 95035
+1 408 309-6081 | g g d r a s i l United States of America
"Free Software For The Rest Of Us."