From: Dominique Martinet <asmadeus@codewreck.org>
To: Eric Sandeen <sandeen@sandeen.net>
Cc: Eric Sandeen <sandeen@redhat.com>,
v9fs@lists.linux.dev, linux-fsdevel@vger.kernel.org,
linux-kernel@vger.kernel.org, ericvh@kernel.org,
lucho@ionkov.net, linux_oss@crudebyte.com, dhowells@redhat.com,
Christian Brauner <brauner@kernel.org>
Subject: Re: [PATCH V2 0/4] 9p: convert to the new mount API
Date: Fri, 15 Aug 2025 10:49:48 +0900 [thread overview]
Message-ID: <aJ6SPLaYUEtkTFWc@codewreck.org> (raw)
In-Reply-To: <6e965060-7b1b-4bbf-b99b-fc0f79b860f8@sandeen.net>
Eric Sandeen wrote on Thu, Aug 14, 2025 at 11:55:20AM -0500:
> >> I was able to test this to some degree, but I am not sure how to test
> >> all transports; there may well be bugs here. It would be great to get
> >> some feedback on whether this approach seems reasonable, and of course
> >> any further review or testing would be most welcome.
> >
> > I still want to de-dust my test setup with rdma over siw for lack of
> > supported hardware, so I'll try to give it a try, but don't necessarily
> > wait for me as I don't know when that'll be..
>
> Any news on testing? :)
Thanks for the prompting, that's the kind of things I never get around
to if not reminded...
I got this to run with a fedora-based host (unlike debian siw is
built-in):
- host side
```
$ sudo modprobe siw
$ sudo rdma link add siw0 type siw netdev br0
(sanity check)
$ ibv_devices
device node GUID
------ ----------------
siw0 020000fffe000001
( https://github.com/chaos/diod build)
$ ./configure --enable-rdma --disable-auth && make -j
(diod run, it runs rdma by default; not squashing as root fails with
rdma because of the ib_safe_file_access check:
[611503.258375] uverbs_write: process 1490213 (diod) changed security contexts after opening file descriptor, this is not allowed.
)
$ sudo ./diod -f -e /tmp/linux-test/ --no-auth -U root -S
```
- guest side (with -net user)
```
# modprobe siw
# rdma link add siw0 type siw netdev eth0
# mount -t 9p -o trans=rdma,aname=/tmp/linux-test <hostip> /mnt
```
I've tested both the new and old mount api (with util-linux mount and
busybox mount) and it all seems in order to me;
as discussed in the other part of the thread we're now failing on
unknown options but I think that's a feature and we can change that if
someone complains.
> As for "waiting for you," I assume that's more for your maintainer peers
> than for me? I'm not sure if this would go through Christian (cc'd) or
> through you?
Sorry, I wasn't paying attention and confused you with another Eric
(Van Hensbergen) who is a 9p maintainer, so I was thinking you'd take
the patches, but that wasn't correct.
And that's after seeing your name all the time in #xfs, I'm sorry..
Christian is "just" a reviewer (for now!), and none of the other
maintainers pick much up lately, so I'll give this a second look and
take the patches.
Linus just closed up 6.17-rc1 so I guess this will get in 6.18 in the
next cycle, unless there'd be a reason to hurry?
Thanks,
--
Dominique Martinet | Asmadeus
next prev parent reply other threads:[~2025-08-15 1:50 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-30 19:18 [PATCH V2 0/4] 9p: convert to the new mount API Eric Sandeen
2025-07-30 19:18 ` [PATCH V2 1/4] fs/fs_parse: add back fsparam_u32hex Eric Sandeen
2025-07-30 19:18 ` [PATCH V2 2/4] net/9p: move structures and macros to header files Eric Sandeen
2025-07-30 19:18 ` [PATCH V2 3/4] 9p: create a v9fs_context structure to hold parsed options Eric Sandeen
2025-07-30 19:18 ` [PATCH V2 4/4] 9p: convert to the new mount API Eric Sandeen
2025-07-30 22:21 ` [PATCH V2 0/4] " asmadeus
2025-07-31 1:38 ` Eric Sandeen
2025-07-31 12:24 ` asmadeus
2025-08-14 16:55 ` Eric Sandeen
2025-08-15 1:49 ` Dominique Martinet [this message]
2025-08-15 2:45 ` Eric Sandeen
2025-08-15 13:55 ` Christian Brauner
2025-08-15 20:53 ` Dominique Martinet
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aJ6SPLaYUEtkTFWc@codewreck.org \
--to=asmadeus@codewreck.org \
--cc=brauner@kernel.org \
--cc=dhowells@redhat.com \
--cc=ericvh@kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux_oss@crudebyte.com \
--cc=lucho@ionkov.net \
--cc=sandeen@redhat.com \
--cc=sandeen@sandeen.net \
--cc=v9fs@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).