Hi,
So took me a while to grok the context, and to understand why it was
working for me, and broken on another machine...
> I have read the context in [1]. It seems your tool has already used new
> mount api to mount the hostfs.
Yes, however, that's a default that's entirely transparent to the user.
This is why I wasn't seeing the errors, depending on the machine I'm
running this on, because the 'mount' tool either uses the old or new
style and the user can never know.
> It now rejects unknown mount options as
> many other filesystems do regardless of its earlier behavior (which
> treats any option as the root directory in hostfs).
And that's clearly the root cause of this regression.
You can't even argue it's not a regression, because before cd140ce9f611
("hostfs: convert hostfs to use the new mount API") it still worked with
the new fsconfig() API, but with the old mount options...
> I'm not sure it is reasonable in this way. If we accept unknown option
> in the hostfs, it will be treated as root directory. But which one
> should be used (like mount -t hostfs -o unknown,/root/directory none
> /mnt). So in the conversion, we introduce the `hostfs` key to mark the
> root directory. May be we need more discussion about use case.
There's only one option anyway, so I'd think we just need to fix this
and not require the hostfs= key. Perhaps if and only if it starts with
hostfs= we can treat it as a key, otherwise treat it all as a dir? But I
guess the API wouldn't make that easy.
Anyway, I dunno, but it seems like a regression to me and we should try
to find a way to fix it.
johannes
