On Wed, 7 Mar 2001, Chaitanya Tumuluri wrote:
>> On Wed, 7 Mar 2001, Peter T. Breuer wrote:
>> "GCS wrote:"
>> I would appreciate it if the patch were less invasive. Has this been
>> done? Surely changing make_request's type is intrinsically a bad idea?
>>
>> I agree that the implementation is clever - setting the bh argument null
>> signals the new make_request to use the remaining args, kiobuff and
>> friends, instead, so only kiobuff-aware code will make use of it. But
>> in that case why not write a separate function? The kernel has
>> provisions for overwriting make_request _cleanly_.
> Agreed. The current state of the code is a historical artifact of trying
> to keep pace with the evolutions in ll_rw_block/__make_request() and
> friends. Originally, we did have a separate make_kio_request() function.
> The provision you mention came in later, at which point in time it was
going
> to be a _lot_ more effort to provide for lvm/md type of remapping in the
> make_kio_request() version. A quicker/easier fix was to modify the
> make_request() signature to handle kiobufs.
Is there any way to determine if the kiobufs support is in the kernel at
compile time? Community members would like to build JFS on the SGI kernel
and in our code we use
generic_make_request(READ, &bp->l_bh); /* 2.4.x kernel */
This call would change to
generic_make_request(READ, &bp->l_bh, NULL, 0, 0, 0); /* kiobufs support */
I would like to find a clean way to ifdef this. Anyone have any ideas
with this one.
Thanks,
Steve
|