2022-09-02 21:35 GMT+09:00, Tom Talpey <tom@xxxxxxxxxx>: > On 9/1/2022 10:11 PM, Jeremy Allison wrote: >> On Fri, Sep 02, 2022 at 09:56:57AM +0900, Namjae Jeon wrote: >>> 2022-09-02 6:48 GMT+09:00, Jeremy Allison <jra@xxxxxxxxx>: >>>> 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 :-). > > The name collision was always a minor thing for me, but when it > goes front and center in the manpage namespace, potentially > coming up for a user when they expected Samba's, it is working > cross-purposes. Ksmbd should forge its own identity, for clarity > and for the future. Okay, I'm talking to Atte to do that. after changing ksmbd-tools with him, I will update ksmbd documentation in kernel. > > Namjae, you should be excited that this kind of issue comes up. > As interest in ksmbd rises, more eyes will be on it, and more > feedback will come. Remember it's experimental, it is not yet > frozen in stone by being adopted by large numbers of users. > Now is the time to work out the usability. Okay. Thank you so much for your good feedbacks as well as the patch review. Please keep giving feedback like it is now:) Thanks JRA also. > Tom. > Let's also pop up a level Yup! >
