Re: [PATCH] net/9p: autoload transport modules

On 2021-11-02 23:58+0900, Dominique Martinet wrote:

Thomas Weißschuh wrote on Tue, Nov 02, 2021 at 03:49:32PM +0100:

quoted

quoted

I guess it wouldn't hurt to have 9p-tcp 9p-unix and 9p-fd aliases to the
9pnet module, but iirc these transports were more closely tied to the
rest of 9pnet than the rest so it might take a while to do and I don't
have much time for this right now...
I'd rather not prepare for something I'll likely never get onto, so
let's do this if there is progress.

Of course if you'd like to have a look that'd be more than welcome :-)

If you are still testing anyways, you could also try the attached patch.
(It requires the autload patch)

It builds fine and I see no reason for it not to work.

Thanks! I'll give it a spin.


I was actually just testing the autoload one and I can't get it to work
on my minimal VM, I guess there's a problem with the usermodhelper call
to load module..

with 9p/9pnet loaded,
running "mount -t 9p -o trans=virtio tmp /mnt"
request_module("9p-%s", "virtio") returns -2 (ENOENT)

Can you retry without 9p/9pnet loaded and see if they are loaded by the mount
process?
The same autoloading functionality exists for filesystems using
request_module("fs-%s") in fs/filesystems.c
If that also doesn't work it would indicate an issue with the kernel setup in general.

Looking at the code it should be running "modprobe -q -- 9p-virtio"
which finds the module just fine, hence my supposition usermodhelper is
not setup correctly

Do you happen to know what I need to do for it?

What is the value of CONFIG_MODPROBE_PATH?
And the contents of /proc/sys/kernel/modprobe?

I've run out of time for today but will look tomorrow if you don't know.

(And since it doesn't apparently work out of the box on these minimal
VMs I think I'll want the trans_fd module split to sit in linux-next
for a bit longer than a few days, so will be next merge window)

Sure.

Thomas