From: asmadeus@codewreck.org
To: Eric Sandeen <sandeen@redhat.com>
Cc: 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
Subject: Re: [PATCH V2 0/4] 9p: convert to the new mount API
Date: Thu, 31 Jul 2025 07:21:17 +0900 [thread overview]
Message-ID: <aIqa3cdv3whfNhfP@codewreck.org> (raw)
In-Reply-To: <20250730192511.2161333-1-sandeen@redhat.com>
Hi Eric,
Eric Sandeen wrote on Wed, Jul 30, 2025 at 02:18:51PM -0500:
> This is an updated attempt to convert 9p to the new mount API. 9p is
> one of the last conversions needed, possibly because it is one of the
> trickier ones!
Thanks for this work!
I think the main contention point here is that we're moving some opaque
logic that was in each transport into the common code, so e.g. an out of
tree transport can no longer have its own options (not that I'm aware of
such a transport existing anyway, so we probably don't have to worry
about this)
OTOH this is also a blessing because 9p used to silently ignore unknown
options, and will now properly refuse them (although it'd still silently
ignore e.g. rdma options being set for a virtio mount -- I guess there's
little harm in that as long as typos are caught?)
So I think I'm fine with the approach.
> 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..
--
Dominique Martinet | Asmadeus
next prev parent reply other threads:[~2025-07-30 22:21 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 ` asmadeus [this message]
2025-07-31 1:38 ` [PATCH V2 0/4] " Eric Sandeen
2025-07-31 12:24 ` asmadeus
2025-08-14 16:55 ` Eric Sandeen
2025-08-15 1:49 ` Dominique Martinet
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=aIqa3cdv3whfNhfP@codewreck.org \
--to=asmadeus@codewreck.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=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).