Re: [PATCH] smb: smbdirect: move fs/smb/common/smbdirect/ to fs/smb/smbdirect/
Linus Torvalds <torvalds-de/[email protected]> Wed, 22 Apr 2026 08:36:33 -0700
| Newsgroups | gmane.linux.drivers.rdma,gmane.linux.kernel.cifs,gmane.linux.network,gmane.network.samba.internals |
|---|---|
| Message-ID | <CAHk-=whHACPH7vBLo8CVSqR5-mgzP4ff7qJU6F=1exKTpQ0-7g@mail.gmail.com> |
On Wed, 22 Apr 2026 at 07:49, Steve French <[email protected]> wrote: > > On Wed, Apr 22, 2026 at 3:16 AM Stefan Metzmacher <[email protected]> wrote: > > > > > > Why is this not in net/smbdirect/ or driver/infiniband/ulp/smdirect? > > > > Yes, I also thought about net/smbdirect. > > I would prefer to leave it in fs/smb for the time being, since it makes it > easier to track since fs/smb/server and fs/smb/client have dependencies > on it. In the long run, I don't mind moving it, if it starts being > used outside of smb client and server. I personally have no hugely strong opinions, but I think Christophs very question that gives two different alternative locations argues for just leaving it in fs/smb/ That driver/infiniband/ulp/smdirect location in particular is just a disgusting path. It sure as hell is *not* a driver, it just uses the rdma infrastructure. If rdma were to eventually itself split itself up into the driver code and non-driver code (like networking does), that might change things, but that's not happening now. And as long as we expect smbdirect code to go through the smb maintainer, I'd rather have the location be about that clear situation rather than some arbitrary "it uses the rdma code" or "it's networking". Because that code is not primarily about networking or about rdma. That code is primarily about smb. So while I have no *strong* opinions and can deal with whatever maintainers find convenient, I think fs/smb/smbdirect is at least currently the sane location. Linus