On Wednesday August 1, [EMAIL PROTECTED] wrote:
>
> In any case, why does something so complicated need to be a macro, why
> not a function instead?
There needs to be a macro so you can put a statement after it to be
executed "for each ..."
But you are right that it doesn't all need to be in the
On Wed, Aug 01, 2007 at 11:52:35AM -0400, John Stoffel wrote:
>
> Tejun> Avi Kivity wrote:
> >> NeilBrown wrote:
> >>> To achieve this, the "for_each" macros are now somewhat more complex.
> >>> For example, rq_for_each_segment is:
> >>>
> >>> #define bio_for_each_segment_offset(bv, bio, _i, offs
Tejun> Avi Kivity wrote:
>> NeilBrown wrote:
>>> To achieve this, the "for_each" macros are now somewhat more complex.
>>> For example, rq_for_each_segment is:
>>>
>>> #define bio_for_each_segment_offset(bv, bio, _i, offs, _size)\
>>> for (_i.i = 0, _i.offset = (bio)->bi_offset + offs,
Avi Kivity wrote:
> NeilBrown wrote:
>> To achieve this, the "for_each" macros are now somewhat more complex.
>> For example, rq_for_each_segment is:
>>
>> #define bio_for_each_segment_offset(bv, bio, _i, offs, _size)\
>> for (_i.i = 0, _i.offset = (bio)->bi_offset + offs,\
>>
NeilBrown wrote:
To achieve this, the "for_each" macros are now somewhat more complex.
For example, rq_for_each_segment is:
#define bio_for_each_segment_offset(bv, bio, _i, offs, _size) \
for (_i.i = 0, _i.offset = (bio)->bi_offset + offs, \
_i.size =
The following 35(!) patches achieve a refactoring of some parts of the
block layer to provide better support for stacked devices.
The core issue is that of letting bio_add_page know the limitation
that the device imposes so that it doesn't create a bio that is too large.
For a unstacked disk dev
6 matches
Mail list logo
