On 2024/11/26 21:50, Johannes Berg wrote:
On Mon, 2024-11-25 at 18:43 +0100, Karel Zak wrote:
The long-term solution would be to clean up hostfs and use named
variables, such as "mount -t hostfs none -o 'path="/home/hostfs"'.
That's what Hongbo's commit *did*, afaict, but it is a regression.
Now most of the regression is that with fsconfig() call it was no longer
possible to specify a bare folder, and then we got discussing what
happens if the folder name actually contains a comma...
But this is still a regression, so we need to figure out what to do
short term?
So for short term, even long term, can we consider handling the hostfs
situation specially within libmount? Such as treat the whole option as
one key(also may be with comma, even with equal), in this case, libmount
will use it as FSCONFIG_SET_FLAG. We can do that because for hostfs, it
only has one mount option, and no need for extension.
Thanks,
Hongbo
Ignoring the "path with comma" issue, because we can't even fix that in
the kernel given what you describe changed in userspace, we can probably
only
1) revert the hostfs conversion to the new API, or
2) somehow not require the hostfs= key?
I don't know if either of those are even possible
Fixing the regression fully (including for paths containing commas)
probably also requires userspace changes. If you don't want to make
those we can only point to your workarounds instead, since we can't do
anything on the kernel side.
I don't know the fsconfig() API, is it possible to have key-less or
value-less calls? What does happen
johannes
