On Mon, Jul 22, 2013 at 11:12 AM, Jeff Layton <jlayton@xxxxxxxxxx> wrote: > On Mon, 22 Jul 2013 11:07:47 -0400 > Scott Lovenberg <scott.lovenberg@xxxxxxxxx> wrote: > >> On Mon, Jul 22, 2013 at 6:53 AM, Jeff Layton <jlayton@xxxxxxxxxx> wrote: >> > On Mon, 22 Jul 2013 09:38:17 +0800 >> > Chen Gang <gang.chen@xxxxxxxxxxx> 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@xxxxxxxxxx> wrote: >> >> > >> >> >> On Fri, 19 Jul 2013 22:44:22 -0400 >> >> >> Scott Lovenberg <scott.lovenberg@xxxxxxxxx> wrote: >> >> >> >> >> >>> On Jul 19, 2013, at 22:34, Steve French <smfrench@xxxxxxxxx> 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@xxxxxxxxxx> >> >> >> 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@xxxxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
