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