[PATCH] cifs-utils: Correct max string lengths

[Scott Lovenberg]

On Mon, Jul 22, 2013 at 11:12 AM, Jeff Layton <jlayton at redhat.com> wrote:
> On Mon, 22 Jul 2013 11:07:47 -0400
> Scott Lovenberg <scott.lovenberg at gmail.com> wrote:
>
>> On Mon, Jul 22, 2013 at 6:53 AM, Jeff Layton <jlayton at redhat.com> wrote:
>> > On Mon, 22 Jul 2013 09:38:17 +0800
>> > Chen Gang <gang.chen at asianux.com> wrote:
>> >
>> >> On 07/20/2013 11:24 PM, Scott Lovenberg wrote:
>> >> >
>> >> >
>> >> > Sent from my iPod
>> >> >
>> >> > On Jul 20, 2013, at 6:43, Jeff Layton <jlayton at redhat.com> wrote:
>> >> >
>> >> >> On Fri, 19 Jul 2013 22:44:22 -0400
>> >> >> Scott Lovenberg <scott.lovenberg at gmail.com> wrote:
>> >> >>
>> >> >>> On Jul 19, 2013, at 22:34, Steve French <smfrench at gmail.com> wrote:
>> >> >>>
>> >> >>>> Leaving Max share length at 256 is fine with me
>> >> >>> Works for me. Should this be fixed kernel side?
>> >> >>
>> >> >> Yes, I think that would make sense. Scott, I assume you'll send a v2 of
>> >> >> this patch that preserves the share length at 256?
>> >> >>
>> >> >> Once that's done, the ideal thing here would be to move these
>> >> >> definitions in the kernel to a separate header file that lives under
>> >> >> include/linux. Then we could have autoconf in cifs-utils look for that
>> >> >> header and use the #defines from that instead if it's present.
>> >> >>
>> >> >> That way we won't be so reliant on keeping the kernel and cifs-utils in
>> >> >> sync...
>> >> >
>> >> > Yeah. I'll respin and send tomorrow. I have a wedding to attend this afternoon.  Using autoconf would be terrific and I'm completely on board with that idea.
>> >> >
>> >>
>> >> Is it better to let the new header file in "include/uapi/linux" ? It
>> >> belongs to the interface between user mode and kernel mode.
>> >>
>> >
>> > That's more of a long-term fix. We'll still need to build cifs-utils
>> > against kernel headers that don't contain that header file, so fixing
>> > the lengths here is needed anyway.
>> >
>> > Once this patch goes in, adding a header in include/uapi/linux that
>> > holds these lengths (and any others that the mount helper and cifs.ko
>> > need to share) would be helpful. Then we could simply look for that
>> > file at autoconf time, and conditionally include it if it exists.
>> >
>> > --
>> > Jeff Layton <jlayton at redhat.com>
>>
>>
>> Since we're doing that we might as well standardize on the variable
>> names.  Should we just make the mount helper use the same variable
>> names as the kernel to avoid confusion?  That will be an external
>> change (ie, changing a non-static variable) if anyone linked to the
>> mount helper (doubtful, but possible) and it will break their code.
>>
>
> The variable names aren't terribly important, so I wouldn't go making
> any sort of change like that for "cleanup". What matters here is the
> names of the preprocessor constants. Those will need to be unified
> between userland and kernel in order to make such a scheme work.
>
> --
> Jeff Layton <jlayton at redhat.com>

Sorry, I articulated that terribly.  I was referring to the
preprocessor constants such that we can just wrap our current
definitions in #ifndef/#endif.  We're on the same page.

--
Peace and Blessings,
-Scott.