Re: [GIT PULL] ksmbd server fixes

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Sounds like a good plan.

On Mon, 22 May 2023 at 14:39, Steve French via samba-technical
<samba-technical@xxxxxxxxxxxxxxx> wrote:
>
> On Sun, May 21, 2023 at 2:21 PM Linus Torvalds
> <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
> >
> > On Sun, May 21, 2023 at 12:03 PM Steve French <smfrench@xxxxxxxxx> wrote:
> > >
> > > I would be happy to do the move (to fs/smb) of the directories and
> > > update the config soon (seems reasonably low risk) - let me know if you
> > > want me to send it this week or wait till 6.5-rc
> >
> > So I think the "do it now or wait until the 6.5 merge window" is
> > entirely up to you.
> >
> > We've often intentionally done big renames during the "quiet time"
> > after the merge window is oven, just because doing them during the
> > merge window can be somewhat painful with unnecessary conflicts.
> >
> > I would *not* want to do it during the last week of the release, just
> > in case there are small details that need to be fixed up, but doing it
> > now during the rc3/rc4 kind of timeframe is not only fairly quiet, but
> > also gives us time to find any surprises.
> >
> > So in that sense, doing it now is likely one of the better times, and
> > a pure rename should not be risky from a code standpoint.
> >
> > At the same time, doing it during the merge window isn't *wrong*
> > either.  Despite the somewhat painful merge with folio changes, I
> > don't think fs/cifs/ or fs/ksmbd/ normally have a lot of conflicts,
> > and git does handle rename conflicts fairly well unless there's just
> > lots of complexity.
> >
> > So it's really fine either way. The normal kind of "big changes"
> > should obviously always be merge window things, but pure renames
> > really are different and are often done outside of the merge window
> > (the same way I intentionally did the MAINTAINERS re-ordering just
> > *after* the merge window)
> >
> > But we don't do renames often enough to have any kind of strict rules
> > about things like this.
> >
> > So I think "whenever is most convenient for you" is the thing to aim
> > for here. This is *not* a "only during merge window" kind of thing.
> >
> >                  Linus
>
> Here are two patches:
> 1)  Move CIFS/SMB3 related client and server files (cifs.ko and ksmbd.ko
> and helper modules) to new fs/smb subdirectory (fs/smbfs was not used
> to avoid confusion with the directory of the same name removed in 2.6.27
> release and we also avoid using CONFIG_SMB_FS for the same reason)
>
>    fs/cifs --> fs/smb/client
>    fs/ksmbd --> fs/smb/server
>    fs/smbfs_common --> fs/smb/common
>
> 2) With the fs/cifs directory moved to fs/smb/client, correct mentions
> of this in Documentation and comments.
>
> Follow on patch can change Documentation/filesystems/cifs -->
> Documentation/filesystems/smb (since it contains both server
> and client documentation)
>
>
> --
> Thanks,
>
> Steve




[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [NTFS 3]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [NTFS 3]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux