On 2024/10/8 16:46, Christian Brauner wrote:
On Tue, Oct 08, 2024 at 10:13:31AM GMT, Gao Xiang wrote:
Hi Christian,
On 2024/10/7 19:35, Christian Brauner wrote:
On Sat, Oct 05, 2024 at 10:41:10PM GMT, Gao Xiang wrote:
...
Hi Christian, if possible, could you give some other
idea to handle this case better? Many thanks!
Thanks for the reply!
(1) Require that the path be qualified like:
fsconfig(<fd>, FSCONFIG_SET_STRING, "source", "file:/home/lis/src/mountcfs/cfs", 0)
and match on it in either erofs_*_get_tree() or by adding a custom
function for the Opt_source/"source" parameter.
IMHO, Users could create names with the prefix `file:`,
it's somewhat strange to define a fixed prefix by the
definition of source path fc->source.
Although there could be some escape character likewise
way, but I'm not sure if it's worthwhile to work out
this in kernel.
(2) Add a erofs specific "source-file" mount option. IOW, check that
either "source-file" or "source" was specified but not both. You
could even set fc->source to "source-file" value and fail if
fc->source is already set. You get the idea.
I once thought to add a new mount option too, yet from
the user perpertive, I think users may not care about
the source type of an arbitary path, and the kernel also
can parse the type of the source path directly... so..
So.. I wonder if it's possible to add a new VFS interface
like get_tree_bdev_by_dev() for filesystems to specify a
device number rather than hardcoded hard-coded source path
way, e.g. I could see the potential benefits other than
the EROFS use case:
- Filesystems can have other ways to get a bdev-based sb
in addition to the current hard-coded source path way;
- Some pseudo fs can use this way to generate a fs from a
bdev.
- Just like get_tree_nodev(), it doesn't strictly tie to
fc->source too.
Also EROFS could lookup_bdev() (this kAPI is already
exported) itself to check if it uses get_tree_bdev_by_dev()
or get_tree_nodev()... Does it sounds good? Many thanks!
Sounds fair to me.
Okay, thanks! Let me submit patches for this.
Thanks,
Gao Xiang
