Hello!

   No, it's not the way to test the kernel version, it's the way to test 
internal
   lustre version.
   Either way maintaining compatibility with Lustre 1.8 and 2.0 servers should 
not
   be important anymore, so it's fine to drop this check indeed.

Bye,
    Oleg
On Oct 11, 2014, at 5:06 PM, Filipe Gonçalves wrote:

> Ah .. right! I didn't know what OBD_OCD_VERSION() was. Now I see it's
> a way to test kernel version. I am going to submit a new patch
> shortly.
> 
> Thanks,
> Filipe
> 
> On Sat, Oct 11, 2014 at 9:15 PM, Greg KH <gre...@linuxfoundation.org> wrote:
>> 
>> On Sat, Oct 11, 2014 at 08:13:42PM +0100, Filipe Gonçalves wrote:
>>> This patch fixes a sparse warning on layout.c (ptlrpc) that was caused by 
>>> having preprocessor directives in the arguments to a macro.
>>> 
>>> Signed-off-by: Filipe Gonçalves <fil...@codinghighway.com>
>>> ---
>>> drivers/staging/lustre/lustre/ptlrpc/layout.c | 7 +++++--
>>> 1 file changed, 5 insertions(+), 2 deletions(-)
>>> 
>>> diff --git a/drivers/staging/lustre/lustre/ptlrpc/layout.c 
>>> b/drivers/staging/lustre/lustre/ptlrpc/layout.c
>>> index 5b83371..211df78 100644
>>> --- a/drivers/staging/lustre/lustre/ptlrpc/layout.c
>>> +++ b/drivers/staging/lustre/lustre/ptlrpc/layout.c
>>> @@ -978,10 +978,11 @@ struct req_msg_field RMF_CONN =
>>> EXPORT_SYMBOL(RMF_CONN);
>>> 
>>> struct req_msg_field RMF_CONNECT_DATA =
>>> +#if LUSTRE_VERSION_CODE > OBD_OCD_VERSION(2, 7, 50, 0)
>>>      DEFINE_MSGF("cdata",
>>>                  RMF_F_NO_SIZE_CHECK /* we allow extra space for interop */,
>>> -#if LUSTRE_VERSION_CODE > OBD_OCD_VERSION(2, 7, 50, 0)
>>>                  sizeof(struct obd_connect_data),
>>> +                 lustre_swab_connect, NULL);
>> 
>> Ick ick ick.
>> 
>> Yeah, sparse might complain about this, but how about just properly
>> deleting the #ifdef entirely, and not perpetuate it even more?
>> 
>> It shouldn't be needed anymore now that the code is in the kernel tree.
>> 
>> greg k-h

_______________________________________________
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Reply via email to