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> -- 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
