Message-ID: <CAH2r5mtEmJdCuG_U3fhk66Luf+XN4xPK5T3ozpOuuDOrTDHncA@mail.gmail.com>
Date: Thu, 4 Dec 2025 19:50:46 -0600
From: Steve French <smfrench@...il.com>
To: ChenXiaoSong <chenxiaosong.chenxiaosong@...ux.dev>
Cc: Namjae Jeon <linkinjeon@...nel.org>, linkinjeon@...ba.org, linux-cifs@...r.kernel.org, 
	linux-kernel@...r.kernel.org, chenxiaosong@...nxiaosong.com, 
	ChenXiaoSong <chenxiaosong@...inos.cn>, "Stefan (metze) Metzmacher" <metze@...ba.org>
Subject: Re: [PATCH 09/10] smb: create common/common.h and common/common.c

On Thu, Dec 4, 2025 at 7:44 PM ChenXiaoSong
<chenxiaosong.chenxiaosong@...ux.dev> wrote:
>
> Now, where should common/smb2maperror.c go? Should it be built into both
> cifs.ko and ksmbd.ko?
>
> Thanks,
> ChenXiaoSong.

I am open to other opinions - especially from Metze and Namjae who are
dealing with similar issues in splitting out the RDMA/smbdirect code,
but I lean toward (at least for now) just including it in both cifs.ko
or ksmbd.ko, or not moving the C code yet (just move to common headers
for #defines, inlined functions that are put in headers etc.).  I
consider moving the common C functions into a common C file used by
cifs.ko and ksmbd.ko is lower priority than other cleanup.

Do you have a list of all of the (general types of) functions that
smb3common.ko could contain?  IIRC you mentioned for mapping errors
but what other routines could easily make it into this proposed common
module with low risk?

>
> On 12/5/25 09:36, Steve French wrote:
> > i lean against an 'smbcommon.ko'   - it can be helpful to move common
> > code (headers, #defines etc) into fs/smb/common but other than
> > smbdirect code (where smbdirect.ko makes sense for cifs.ko, ksmbd.ko,
> > Samba and user space AI apps e.g. to use), I lean against creating new
> > modules for the client and server.
> >
> > ksmbd.ko for server code
> > cifs.ko (or maybe someday renamed to smb3.ko) for client code
> > smbdirect.ko for the RDMA/smbdirect code shared by ksmbd/cifs.ko/userspace tools
> >
> > maybe (as they did for the md4 code creating an cifs_md4.ko so that
> > less secure code doesn't have to be linked in if unneeded) someday we
> > could split an "smb1.ko" out for the SMB1 related code (since we want
> > to discourage use of old insecure dialects, and could shrink cifs.ko,
> > and slightly simplify it)
> >
> > Finding common code is good - but let's not complicate things by
> > creating lots of new modules - in the short term the focus is on
> > sanely splitting the common RDMA/smbdirect code out (because 1) it is
> > large enough 2) it will have use cases outside of cifs.ko and
> > ksmbd.ko).  But I lean against creating multiple new modules in the
> > short term.
> >
> > On Thu, Dec 4, 2025 at 6:59 PM ChenXiaoSong
> > <chenxiaosong.chenxiaosong@...ux.dev> wrote:
> >>
> >> OK, I will create new smb2maperror.ko and will send v2 soon.
> >>
> >> Thanks for your review and suggestions.
> >>
> >> Thanks,
> >> ChenXiaoSong.
> >>
> >> On 12/5/25 08:35, Namjae Jeon wrote:
> >>> On Thu, Dec 4, 2025 at 2:00 PM <chenxiaosong.chenxiaosong@...ux.dev> wrote:
> >>>>
> >>>> From: ChenXiaoSong <chenxiaosong@...inos.cn>
> >>>>
> >>>> Preparation for moving client/smb2maperror.c to common/.
> >>>>
> >>>> We can put cifs_md4 and smb2maperror into a single smb_common.ko,
> >>>> instead of creating two separate .ko (cifs_md4.ko and smb2maperror.ko).
> >>> Sorry, I prefer not to create new *.ko for only smb2maperror.
> >>>>
> >>>>     - rename md4.h -> common.h, and update include guard
> >>>>     - create common.c, and move module info from cifs_md4.c into common.c
> >>> ksmbd does not use md4 in smb/common, I don't prefer this either.
> >>> I would appreciate it if you could send me the patch set again except these.
> >>>>
> >>>> Signed-off-by: ChenXiaoSong <chenxiaosong@...inos.cn>
> >>
> >
> >
>


-- 
Thanks,

Steve

Powered by blists - more mailing lists