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

[Tom Talpey <tom@talpey.com>]

On 9/1/2022 2:30 PM, Jeremy Allison wrote:
> On Thu, Sep 01, 2022 at 08:41:08PM +0300, atheik wrote:
>> On Thu, 1 Sep 2022 09:14:31 -0700, Jeremy Allison wrote:
>>> On Thu, Sep 01, 2022 at 09:06:07AM -0400, Tom Talpey wrote:
>>>>
>>>> Ok, two things. What I found strange is the "man smb.conf.5ksmbd", and
>>>> as you say that should be man 5k smb.conf. Sounds ok to me.
>>>>
>>>> But the second thing I'm concerned about is the reuse of the smb.conf
>>>> filename. It's perfectly possible to install both Samba and ksmbd on
>>>> a system, they can be configured to use different ports, listen on
>>>> different interfaces, or any number of other deployment approaches.
>>>>
>>>> And, Samba provides MUCH more than an SMB server, and configures many
>>>> other services in smb.conf. So I feel ksmbd should avoid such filename
>>>> conflicts. To me, calling it "ksmbd.conf" is much more logical.
>>>
>>> +1 from me. Having 2 conflicting file contents both wanting
>>> to be called smb.conf is a disaster waiting to happen.
>>
>> ksmbd-tools clearly has a goal of being compatible with smb.conf(5) of
>> Samba when it comes to the common subset of functionality they share.
>> ksmbd-tools has 7 global parameters that Samba does not have, but other
>> than, share parameters and global parameters of ksmbd-tools are subset
>> of those in Samba. Samba and ksmbd-tools do not have any conflicting
>> file locations. The smb.conf(5ksmbd) man page of ksmbd-tools does not
>> collide with and never overshadows smb.conf(5) of Samba. Please, help
>> me understand what sort of disaster this could lead to.
> 
> Samba adds and or changes functionality in smb.conf all
> the time, without coordination with ksmbd. If you call
> your config file smb.conf then we would have to coordinate
> with you before any changes.

And vice-versa. For example, ksmbd supports RDMA and can be
configured to use interfaces with kernel-internal names,
for example "enp2s0" or "mlx5/1". These files do not in fact
subset one another, in either direction.

> Over time, the meaning/use/names of parameters will drift
> apart leading to possible conflicts.

Personally I think they're already in conflict, having taken
several days to work them all out wile setting up my new
machines. And, um, I think I know what I'm doing. Heaven
help the newbie.

> Plus it leads to massive user confusion (am I running
> smbd or ksmbd ? How do I tell ? etc.).

+1

Tom.

> It is simple hygene to keep these names separate.
> 
> Please do so.
>