On Mon, Oct 28, 2019 at 06:23:02PM +0000, Antti Kantee wrote: > >Did this ever work in a RUMP_USE_CTOR world?
> 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. No worries. I was mostly curious because I couldn't find out in the time I was willing to spend on archaeology. > >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. I did re-read it last night. Apparently not much stuck from the last times. But the code was pretty obvious. IMHO the version in the thesis is more useful because it goes into a bit more interesting detail. BTW, thanks again for giving me a copy of the thesis! > >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. Are you thinking of RUMP_LDSCRIPT making the selection in sys/rump/Makefile.rump? I'm not sure how that would help. Unless you are thinking of doing a special build of buildrump.sh for fs-utils. More interesting, to me anyway, would be finding out what the buildrump.sh build ended up using so fs-utils can autoconfigure off that. > 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. I didn't realize before that without -t fs-utils is supposed to dlopen() all fs drivers. Good to know. Doing it that way ought to work, I'd say without looking further at the code. Not sure about the performance. fsu_df and fsu_cat are noticably slow to start up in the VM. But then, they have to load all the factions and components from NFS due to the setup. (And I don't really want to know why stuff like sppp_subr is need by the network stack unconditionally these days.) It wouldn't be a major concern in the main use case I'm envisaging because using fs-utils would save me from recreating and coyping gigabytes of file system images. > Can't remember if figuring out "correct driver(s)" needs > some special handling, and if that handling is already in fs-utils. Can't say. There is some special handling for nsmb which currently seems to fail. But i've not looked at that yet. > 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. My main goal was to "air out" my "discoveries" from dinking around in a somewhat frazzeled state last week in a somewhat organized and orderly fashion in order to set my brain working on it in the background. Will probably take a while as i'll be traveling a bunch the next weeks and need to prepare for that. I don't mind some amount of yak shaving. Especially if it saves me shaving more yaks in the future. Read: I'd rather do it right once then doing it wrong multiple times. Of course, getting it right might need multiple iterations. The one thing i'm pretty sure about is that the module ctors/dtors should not register the modinfo depending on "cold" but rather always. I'll have to run the NetBSD atf test suite and make sure that nothing breaks when making that change. Besides that I would appreciate a simple API that handles both cases as transparently as possible to the user. I.e. not needing detailed knowledge about ctors/dtors, linksets and in what mode the components were actually compiled. That would be nice. > >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. > 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. Yeah. Or possibly even a "verbose" flag. > >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 ;-) :-) --chris
