On 28/10/2019 00:58, Christoph Badura wrote:
Last week I looked at using fs-utils with buildrump.sh off NetBSD-current
sources.
The main obstacle is with initializing the shared library for the file
system driver after dlopen()ing it.
Oh right, fs-utils loads/initializes the file system drivers dynamically
per demand to minimize startup time.
Did this ever work in a RUMP_USE_CTOR world? I've looked at the log
from the last successful Travis CI build and couldn't figure out wether it
used ctors or linksets. AFAICT it must have used linksets but according
to the git commit ids it should have used ctors. It would be somewhat
interesting to know for sure.
I can't remember for sure. Probably not. Have to keep in mind that
Arnaud wrote fs-utils before even the linksets worked by anything except
accident.
The first problem with ctors is in sys/module.h where the modinfo is only
added to modinfo_boot_chain iff cold. This means that any module loaded
after the rumpkernel has been booted, won't have its modinfo structure
added to modinfo_boot_chain preventing any attempt to module_builtin_add()
its modinfo struct.
The more annoying problem with ctors is about how to get at
modinfo_boot_chain in order to module_builtin_add() its modinfo struct and
call the module's init function to register with the VFS faction.
We have rump_pub_module_init() which takes an array of modinfo structs
as parameter. fs-utils uses dlsym() to look up the addresses of these
structs in the shared library. This does not work in the RUMP_USE_CTOR
case, because the linksets don't exist.
I assume you read section 3.8 from the book. Not that there's anything
wrong with what you said, but it might give additional insights.
Alas, RUMP_USE_CTOR is only define in sys/rump/Makefile.rump during the
buildrump.sh build and not availabe to fs-utils at build time.
Hmm, yea. I can see why that would be a problem here. Wasn't there at
least one way to pass compile time options? I really don't remember now.
I cannot access rumpns_modinfo_boot_chain from gdb in the Ubuntu Xenial VM
that I use for testing. That may or may not be a gdb bug.
As a quick hack I added rump_pub_module_modinfo() which returns the
address of the first modinfo structure on the modinfo_boot_chain and
rump_pub_module_init()ed that. That got the sysvbfs module used in the
tests registered with the VFS layer and the tests to succeed.
Hmm. Would the following work: dlopen() the correct driver(s) before
rump_init() if -t is given, otherwise dlopen() all drivers before
rump_init() instead of trying them in most-likely order. That approach
gives you a fast-path, and if you're not using -t, you probably don't
care about the performance hit of linking/loading all drivers. Can't
remember if figuring out "correct driver(s)" needs some special
handling, and if that handling is already in fs-utils.
We can still talk about the modinfo stuff if you want to, but I'll save
some typing on my part for now, since I assume you're more interested in
making fs-utils work than proceeding with yak shaving.
Note that the kernel messages are inappropriately going to stdout, though.
Fs-utils really needs to send them to stderr. But that's a secondary
theatre.
yea. there should be more control over where what sends output, but
there isn't ...
In this case the non-application part of fs-utils and the rump kernel
should definitely not send output to stdout. Not sure if it should go
even to stderr in the default case, or if that should be behind a
"debug-me" flag. Just thinking out loud.
All with a view to eventually make all this work on macOS. But that is a
bridge to burn after I've crossed the Linux bridge.
It's certainly more efficient to burn bridges before building them ;-)
