Re: [PATCH V2 0/4] 9p: convert to the new mount API

[asmadeus@codewreck.org]

Eric Sandeen wrote on Wed, Jul 30, 2025 at 08:38:17PM -0500:
> > 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)
> 
> I had not thought about out of tree transports. And I was a little unsure
> about moving everything into fs/9p/* but I'm not sure I saw any other way
> to do it in the new framework. @dhowells?

I've had a quick look as well and I don't see either -- parameters are
parsed one at a time so we can't do the two passes needed to first get
the transport out of the arguments and then instantiate a transport and
parse again.
I really think it's fine in practice, just something to remember.

> > 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?)
> 
> Well, that might be considered a regression. Such conversions have burned
> us before, so if you want, it might be possible to keep the old more
> permissive behavior ... I'd have to look, not sure.

From my understanding we just need to make v9fs_parse_param return 0
instead of 'opt' if fs_parse() < 0, but I think it's fine to error on
unknown options (more in line with other filesystems at least)
We can reconsider this and make it a non-error when or if someone
complains about it.

-- 
Dominique Martinet | Asmadeus