[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <aS47OBYiF1PBeVSv@codewreck.org>
Date: Tue, 2 Dec 2025 10:04:56 +0900
From: Dominique Martinet <asmadeus@...ewreck.org>
To: Eric Sandeen <sandeen@...hat.com>
Cc: Remi Pommarel <repk@...plefau.lt>, v9fs@...ts.linux.dev,
linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
ericvh@...nel.org, lucho@...kov.net, linux_oss@...debyte.com,
eadavis@...com
Subject: Re: [PATCH V3 4/4] 9p: convert to the new mount API
Eric Sandeen wrote on Mon, Dec 01, 2025 at 04:36:58PM -0600:
> I suppose it would be a terrible hack to just extend the enum to include
> hexadecimal "strings" like this, right.... ;)
Yeah, that might work for all intent and purposes but we'll get someone
who mounted with cache=0x3 next... :)
> I think the right approach would be to just reinstate get_cache_mode() to
> do open-coded parsing as before, and get rid of the enum for the cache
> option.
This sounds good to me!
> Would you like me to send a patch 5/4, or an updated 4/4 to implement this,
> or would you rather do it yourself if you think you have a better chance
> of getting it right than I do?
No strong feeling either way but I think a 5/4 would be better to
clarify why we do this -- I could probably do it as well but I'd
definietly appreciate if you could do it (and I'll just have to make
time to test at the end!)
> As for the other enum, I think we're still ok (though maybe you can confirm)
> because p9_show_client_options() still does a switch on clnt->proto_version,
> and outputs the appropriate mount option string.
Thanks for checking as well!
--
Dominique
Powered by blists - more mailing lists