On November 3, I wrote:
>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.
Here is an updated version of the patch. The struct
io_restrictions declaration is in <linux/device-mapper.h> so that the
device-mapper user level utilities compile properly (device-mapper.h
is written to support inclusion by user level programs). I have hand
edited this patch to exclude unrelated changes in my tree, so some of
the line numbers will be off. I actually "faked" the changes for
drivers/block/{ll_rw_blk,loop}.c because there was too much
intermingling with my other changes, but I've verified that these
"fake" files compile without warnings related to my changes. I have
also verified that device-mapper-0.96.07 builds with these changes
present.
I expect this patch will enable other clean-ups in the future.
For example, I think most block device drivers, including scsi
controller drivers, will be able to just declare a static struct
io_restrictions that can be copied into the corresponding q->limits
record for each detected device. Eventually, this change may also
help in applying you gather-scatter merging code to other users of DMA
gather/scatter.
Anyhow, I've done what you asked by waiting a few weeks. If
this patch looks OK to you, could you please integrate it into your
queue for Linus? Thanks in advance.
--
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 Wed, Nov 27, 2002 at 11:49:40AM -0800, Adam J. Richter wrote:
> Here is an updated version of the patch. The struct
> io_restrictions declaration is in <linux/device-mapper.h> so that the
> device-mapper user level utilities compile properly (device-mapper.h
> is written to support inclusion by user level programs).
They shouldn't include it anyway. Please put it into a proper place.
>On Wed, Nov 27, 2002 at 11:49:40AM -0800, Adam J. Richter wrote:
>> Here is an updated version of the patch. The struct
>> io_restrictions declaration is in <linux/device-mapper.h> so that the
>> device-mapper user level utilities compile properly (device-mapper.h
>> is written to support inclusion by user level programs).
>They shouldn't include it anyway. Please put it into a proper place.
I don't know what you mean by "shouldn't" or "proper" in this
context. If you'd state technical advantages or disadvanges, others
could determine these labels for themselves.
Anyhow, what would be a "proper" place as you see it?
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 Wed, Nov 27, 2002 at 12:59:46PM -0800, Adam J. Richter wrote:
> >On Wed, Nov 27, 2002 at 11:49:40AM -0800, Adam J. Richter wrote:
> >> Here is an updated version of the patch. The struct
> >> io_restrictions declaration is in <linux/device-mapper.h> so that the
> >> device-mapper user level utilities compile properly (device-mapper.h
> >> is written to support inclusion by user level programs).
>
> >They shouldn't include it anyway. Please put it into a proper place.
>
> I don't know what you mean by "shouldn't" or "proper" in this
> context. If you'd state technical advantages or disadvanges, others
> could determine these labels for themselves.
>
> Anyhow, what would be a "proper" place as you see it?
blkdev.h
Christoph Hellwig wrote:
>On Wed, Nov 27, 2002 at 12:59:46PM -0800, Adam J. Richter wrote:
>> >On Wed, Nov 27, 2002 at 11:49:40AM -0800, Adam J. Richter wrote:
>> >> Here is an updated version of the patch. The struct
>> >> io_restrictions declaration is in <linux/device-mapper.h> so that the
>> >> device-mapper user level utilities compile properly (device-mapper.h
>> >> is written to support inclusion by user level programs).
>>
>> >They shouldn't include it anyway. Please put it into a proper place.
>>
>> I don't know what you mean by "shouldn't" or "proper" in this
>> context. If you'd state technical advantages or disadvanges, others
>> could determine these labels for themselves.
>>
>> Anyhow, what would be a "proper" place as you see it?
>blkdev.h
I expect struct io_restrictions to be useful beyond blkdev. I
want to evolve it for use in DMA scatterlists in general, so blkdev.h
could only be a temporary home. If you really want and nobody else
objects, I'd be willing to create a separate .h file for struct
io_restrictions. (I assume that what you find "improper" about
device-mapper.h is that block devices themselves do not depend
on any abstractions specific to the device mapper.)
That would not break device-mapper, and you could take the
less disruptive approach of submitting a patch to glibc and/or
device-mapper to eliminate the user level program including kernel
headers.
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."