* Re: [PATCH] smb: smbdirect: move fs/smb/common/smbdirect/ to fs/smb/smbdirect/ [not found] <20260419192018.3046449-1-metze@samba.org> @ 2026-04-22 6:31 ` Christoph Hellwig 2026-04-22 8:16 ` Stefan Metzmacher 0 siblings, 1 reply; 6+ messages in thread From: Christoph Hellwig @ 2026-04-22 6:31 UTC (permalink / raw) To: Stefan Metzmacher Cc: linux-cifs, samba-technical, Linus Torvalds, Steve French, Tom Talpey, Long Li, Namjae Jeon, linux-rdma, netdev > diff --git a/fs/smb/Makefile b/fs/smb/Makefile > index 9a1bf59a1a65..353b1c2eefc4 100644 > --- a/fs/smb/Makefile > +++ b/fs/smb/Makefile > @@ -1,5 +1,6 @@ > # SPDX-License-Identifier: GPL-2.0 > > obj-$(CONFIG_SMBFS) += common/ > +obj-$(CONFIG_SMBDIRECT) += smbdirect/ Why is this not in net/smbdirect/ or driver/infiniband/ulp/smdirect? As far as I can tell there is zero file system logic in this code. > -#include "../common/smbdirect/smbdirect_public.h" > +#include "../smbdirect/public.h" And all these relative includes suggest you really want a include/linux/smdirect/ instead. While we're at it: __SMBDIRECT_EXPORT_SYMBOL__ is really odd. One thing is the __ pre- and postfix that make it look weird. The other is that EXPORT_SYMBOL_FOR_MODULES is for very specific symbols that really should not exported. What this warrants instead is a normal EXPORT_SYMBOL_NS_GPL. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] smb: smbdirect: move fs/smb/common/smbdirect/ to fs/smb/smbdirect/ 2026-04-22 6:31 ` [PATCH] smb: smbdirect: move fs/smb/common/smbdirect/ to fs/smb/smbdirect/ Christoph Hellwig @ 2026-04-22 8:16 ` Stefan Metzmacher 2026-04-22 14:49 ` Steve French 2026-04-23 5:52 ` Christoph Hellwig 0 siblings, 2 replies; 6+ messages in thread From: Stefan Metzmacher @ 2026-04-22 8:16 UTC (permalink / raw) To: Christoph Hellwig Cc: linux-cifs, linux-rdma, netdev, samba-technical, Tom Talpey, Steve French, Linus Torvalds, Namjae Jeon Hi Christoph, >> diff --git a/fs/smb/Makefile b/fs/smb/Makefile >> index 9a1bf59a1a65..353b1c2eefc4 100644 >> --- a/fs/smb/Makefile >> +++ b/fs/smb/Makefile >> @@ -1,5 +1,6 @@ >> # SPDX-License-Identifier: GPL-2.0 >> >> obj-$(CONFIG_SMBFS) += common/ >> +obj-$(CONFIG_SMBDIRECT) += smbdirect/ > > Why is this not in net/smbdirect/ or driver/infiniband/ulp/smdirect? Yes, I also thought about net/smbdirect. As IPPROTO_SMBDIRECT or PF_SMBDIRECT will be the next step, see the open discussion here: https://lore.kernel.org/linux-cifs/cover.1775571957.git.metze@samba.org/ (I'll follow with that discussion soon) I was just unsure about the consequences, e.g. would the maintainer/pull request flow have to change in that case? Or would Steve be able to take the changes via his trees? Any I also didn't want to offend anybody, so I just took what Linus proposed. Using driver/infiniband/ulp/smdirect would also work, if everybody prefer that. > As far as I can tell there is zero file system logic in this code. > >> -#include "../common/smbdirect/smbdirect_public.h" >> +#include "../smbdirect/public.h" > > And all these relative includes suggest you really want a > include/linux/smdirect/ instead. Yes, that's my also my goal in the next steps. > While we're at it: __SMBDIRECT_EXPORT_SYMBOL__ is really odd. > One thing is the __ pre- and postfix that make it look weird. Yes, the __SMBDIRECT_EXPORT_SYMBOL__ was mainly a temporary thing, now it's useless and I'll remove it. > The other is that EXPORT_SYMBOL_FOR_MODULES is for very specific > symbols that really should not exported. What this warrants instead > is a normal EXPORT_SYMBOL_NS_GPL. I want the exported functions be minimal, as most of of should go via the socket layer instead. If EXPORT_SYMBOL_NS_GPL(func, "smbdirect") is better than EXPORT_SYMBOL_FOR_MODULES() I can change that. It means cifs.ko and ksmbd.ko would need MODULE_IMPORT_NS("smbdirect"), correct? Thanks! metze ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] smb: smbdirect: move fs/smb/common/smbdirect/ to fs/smb/smbdirect/ 2026-04-22 8:16 ` Stefan Metzmacher @ 2026-04-22 14:49 ` Steve French 2026-04-22 15:16 ` Paulo Alcantara 2026-04-22 15:36 ` Linus Torvalds 2026-04-23 5:52 ` Christoph Hellwig 1 sibling, 2 replies; 6+ messages in thread From: Steve French @ 2026-04-22 14:49 UTC (permalink / raw) To: Stefan Metzmacher Cc: Christoph Hellwig, linux-cifs, linux-rdma, netdev, samba-technical, Tom Talpey, Linus Torvalds, Namjae Jeon On Wed, Apr 22, 2026 at 3:16 AM Stefan Metzmacher <metze@samba.org> wrote: > > Hi Christoph, > > >> diff --git a/fs/smb/Makefile b/fs/smb/Makefile > >> index 9a1bf59a1a65..353b1c2eefc4 100644 > >> --- a/fs/smb/Makefile > >> +++ b/fs/smb/Makefile > >> @@ -1,5 +1,6 @@ > >> # SPDX-License-Identifier: GPL-2.0 > >> > >> obj-$(CONFIG_SMBFS) += common/ > >> +obj-$(CONFIG_SMBDIRECT) += smbdirect/ > > > > 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. > As IPPROTO_SMBDIRECT or PF_SMBDIRECT will be the next step, > see the open discussion here: > https://lore.kernel.org/linux-cifs/cover.1775571957.git.metze@samba.org/ > (I'll follow with that discussion soon) > > I was just unsure about the consequences, e.g. would > the maintainer/pull request flow have to change in that case? > Or would Steve be able to take the changes via his trees? > Any I also didn't want to offend anybody, so I just took > what Linus proposed. > > Using driver/infiniband/ulp/smdirect would also work, > if everybody prefer that. > > > As far as I can tell there is zero file system logic in this code. > > > >> -#include "../common/smbdirect/smbdirect_public.h" > >> +#include "../smbdirect/public.h" > > > > And all these relative includes suggest you really want a > > include/linux/smdirect/ instead. > > Yes, that's my also my goal in the next steps. > > > While we're at it: __SMBDIRECT_EXPORT_SYMBOL__ is really odd. > > One thing is the __ pre- and postfix that make it look weird. > > Yes, the __SMBDIRECT_EXPORT_SYMBOL__ was mainly a temporary > thing, now it's useless and I'll remove it. > > > The other is that EXPORT_SYMBOL_FOR_MODULES is for very specific > > symbols that really should not exported. What this warrants instead > > is a normal EXPORT_SYMBOL_NS_GPL. > > I want the exported functions be minimal, as most of > of should go via the socket layer instead. > > If EXPORT_SYMBOL_NS_GPL(func, "smbdirect") is better than > EXPORT_SYMBOL_FOR_MODULES() I can change that. > > It means cifs.ko and ksmbd.ko would need MODULE_IMPORT_NS("smbdirect"), correct? > > Thanks! > metze -- Thanks, Steve ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] smb: smbdirect: move fs/smb/common/smbdirect/ to fs/smb/smbdirect/ 2026-04-22 14:49 ` Steve French @ 2026-04-22 15:16 ` Paulo Alcantara 2026-04-22 15:36 ` Linus Torvalds 1 sibling, 0 replies; 6+ messages in thread From: Paulo Alcantara @ 2026-04-22 15:16 UTC (permalink / raw) To: Steve French, Stefan Metzmacher Cc: Christoph Hellwig, linux-cifs, linux-rdma, netdev, samba-technical, Tom Talpey, Linus Torvalds, Namjae Jeon Steve French <smfrench@gmail.com> writes: > On Wed, Apr 22, 2026 at 3:16 AM Stefan Metzmacher <metze@samba.org> wrote: >> >> Hi Christoph, >> >> >> diff --git a/fs/smb/Makefile b/fs/smb/Makefile >> >> index 9a1bf59a1a65..353b1c2eefc4 100644 >> >> --- a/fs/smb/Makefile >> >> +++ b/fs/smb/Makefile >> >> @@ -1,5 +1,6 @@ >> >> # SPDX-License-Identifier: GPL-2.0 >> >> >> >> obj-$(CONFIG_SMBFS) += common/ >> >> +obj-$(CONFIG_SMBDIRECT) += smbdirect/ >> > >> > 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. Please let's not break backporting any further. Decide where it will end up at once. We don't want the "fs/cifs -> fs/smb/client" history all over again. Won't samba be using it? If so, you could consider an user outside fs/smb/{client,server} and then leave it in net/ instead, as hch suggested. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] smb: smbdirect: move fs/smb/common/smbdirect/ to fs/smb/smbdirect/ 2026-04-22 14:49 ` Steve French 2026-04-22 15:16 ` Paulo Alcantara @ 2026-04-22 15:36 ` Linus Torvalds 1 sibling, 0 replies; 6+ messages in thread From: Linus Torvalds @ 2026-04-22 15:36 UTC (permalink / raw) To: Steve French Cc: Stefan Metzmacher, Christoph Hellwig, linux-cifs, linux-rdma, netdev, samba-technical, Tom Talpey, Namjae Jeon On Wed, 22 Apr 2026 at 07:49, Steve French <smfrench@gmail.com> wrote: > > On Wed, Apr 22, 2026 at 3:16 AM Stefan Metzmacher <metze@samba.org> 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] smb: smbdirect: move fs/smb/common/smbdirect/ to fs/smb/smbdirect/ 2026-04-22 8:16 ` Stefan Metzmacher 2026-04-22 14:49 ` Steve French @ 2026-04-23 5:52 ` Christoph Hellwig 1 sibling, 0 replies; 6+ messages in thread From: Christoph Hellwig @ 2026-04-23 5:52 UTC (permalink / raw) To: Stefan Metzmacher Cc: Christoph Hellwig, linux-cifs, linux-rdma, netdev, samba-technical, Tom Talpey, Steve French, Linus Torvalds, Namjae Jeon, Ilya Dryomov, Alex Markuze, Viacheslav Dubeyko, ceph-devel, Jeff Layton, linux-nfs On Wed, Apr 22, 2026 at 10:16:41AM +0200, Stefan Metzmacher wrote: > > Why is this not in net/smbdirect/ or driver/infiniband/ulp/smdirect? > > Yes, I also thought about net/smbdirect. > > As IPPROTO_SMBDIRECT or PF_SMBDIRECT will be the next step, > see the open discussion here: > https://lore.kernel.org/linux-cifs/cover.1775571957.git.metze@samba.org/ > (I'll follow with that discussion soon) Seems like it is the right fit then. > I was just unsure about the consequences, e.g. would > the maintainer/pull request flow have to change in that case? > Or would Steve be able to take the changes via his trees? > Any I also didn't want to offend anybody, so I just took > what Linus proposed. You might want to ask the sunrpc or ceph maintainers as they have a similar split. ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2026-04-23 5:52 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20260419192018.3046449-1-metze@samba.org>
2026-04-22 6:31 ` [PATCH] smb: smbdirect: move fs/smb/common/smbdirect/ to fs/smb/smbdirect/ Christoph Hellwig
2026-04-22 8:16 ` Stefan Metzmacher
2026-04-22 14:49 ` Steve French
2026-04-22 15:16 ` Paulo Alcantara
2026-04-22 15:36 ` Linus Torvalds
2026-04-23 5:52 ` Christoph Hellwig
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox