[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aIqa3cdv3whfNhfP@codewreck.org>
Date: Thu, 31 Jul 2025 07:21:17 +0900
From: asmadeus@...ewreck.org
To: Eric Sandeen <sandeen@...hat.com>
Cc: v9fs@...ts.linux.dev, linux-fsdevel@...r.kernel.org,
linux-kernel@...r.kernel.org, ericvh@...nel.org, lucho@...kov.net,
linux_oss@...debyte.com, dhowells@...hat.com
Subject: Re: [PATCH V2 0/4] 9p: convert to the new mount API
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
Powered by blists - more mailing lists