Re: [PATCH 09/10] smb: create common/common.h and common/common.c

[ChenXiaoSong <chenxiaosong.chenxiaosong@linux.dev>]

Alternatively, we could consider placing MD4 into an smb1_common.ko, and 
creating an smb2_common.ko for the SMB2/3 common code. What do you think?

Thanks,
ChenXiaoSong.

On 12/5/25 09:50, Steve French wrote:
> On Thu, Dec 4, 2025 at 7:44 PM ChenXiaoSong
> <chenxiaosong.chenxiaosong@linux.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@linux.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@linux.dev> wrote:
>>>>>>
>>>>>> From: ChenXiaoSong <chenxiaosong@kylinos.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@kylinos.cn>
>>>>
>>>
>>>
>>
> 
>