Re: [PATCH 1/2] ksmbd: update documentation

[Jeremy Allison <jra@samba.org>]

On Fri, Sep 02, 2022 at 09:56:57AM +0900, Namjae Jeon wrote:
>2022-09-02 6:48 GMT+09:00, Jeremy Allison <jra@samba.org>:
>> On Thu, Sep 01, 2022 at 04:37:21PM -0500, Steve French wrote:
>>>
>>>I do like that Namjae et al made the format of the .conf file very similar
>>>to the format of Samba's smb.conf file though.   I realize there some
>>>users complain that there are too many smb.conf parameters for Samba,
>>>but he seemed to pick a reasonably subset of them for ksmbd.
>>>Samba is a much larger project with many more smb.conf parameters
>>>but it does reduce confusion making the parameter names similar
>>>where possible e.g. "workgroup", "guest account", (share) path, read only,
>>> etc.
>>>and fortunately the default directories for the two smb.conf files are
>>>different so at least the daemons don't use the same file.
>>
>> Sure, I think the formats and parameter names being as close
>> as possible is a great idea to allow users to move between
>> servers as they wish. But making the files the same name
>> is not a good idea.
>This is the first time I've heard that it is problem that ksmbd's
>config filename is same with samba's one. Reading the mail threads, I
>don't understand exactly what the real problem is... I thought that
>using same smb.conf name make users aware that it was forked from
>samba's one. I'm a little surprised, I thought that you will say that
>we should use the same name. This seems to contradict your previous
>opinion that ksmbd's dos attribute and stream xattr format should be
>the same with samba's one. It's not difficult to change config
>filename of ksmbd if you agree with it. If we think about adding the
>ksmbd integration feature in samba recently, I think it would be
>better to use the same name for future.

Well as Tom said, it gets very confusing to have the
same name config file.

The file system attributes etc. certainly should be
the same, to allow a user to swap between the two
servers based on need and not lose any meta-data.

But as the features diverge, trying to keep a common
config will get harder and harder.

Better to take the pain now, rather than try and
postpone for later. It'll hurt *worse* later :-).