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

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

MD4 is also used in SMB2_sess_auth_rawntlmssp_authenticate(), so for now 
we won't move smb2maperror to common/. We can reconsider this in the 
future when ksmbd actually needs to use smb2maperror.

Thanks,
ChenXiaoSong.

On 12/5/25 10:14, ChenXiaoSong wrote:
> 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>
>>>>>
>>>>
>>>>
>>>
>>
>>
>