On Wed, Oct 30, 2019 at 10:07:07PM +0000, Antti Kantee wrote: > On 30/10/2019 00:13, Christoph Badura wrote: > Thesis is more interesting than what, the updated book?
Yes. > Figures, > v2.0 always sucks. I tried to delete the non-interesting irrelevant > parts during the update, but guess I managed the exact opposite. It's not that bad. And it is really difficult to judge what others would find interesting or missing when you are familiar with something. In my experience you notice only on the first reading. > Oh that must've been eons ago. Yea, hardcopies are nice. Every > year or so it occurs to me that I should put also the updated book > onto dead trees, but then reality reminds that it's a lot of work > for selling the estimated 3 copies. Just upload the PDF to lulu.com? > >More interesting, to me anyway, would be finding out what the buildrump.sh > >build ended up using so fs-utils can autoconfigure off that. > > That's what I meant, pass buildrump.sh's compile-time options to its > consumers. Ideally those options wouldn't be needed, but the world > isn't ideal. Ah. Yeah, that could be helpful. > >I didn't realize before that without -t fs-utils is supposed to dlopen() > >all fs drivers. Good to know. > > I don't know, but that's how I remember/imagine it would work: if a > type is not given, fs-utils tries all available ones until a driver > can mount the image, or it runs out of drivers to try and returns > FAIL. It didn't occur to me it would try because the NetBSD commands don't. Or I have not tried to use such a feature in the last 2 decades. :-) > If networking is slowing things down, I guess the same approach as > above can be applied: don't dlopen() the networking faction (and > whatever crap it wants) unless -t nfs or -t smbfs is given. Or use > some magic variant thereof, e.g. if the device string doesn't test > as a file. Sorry. I was obliquely referring that apparently a lot of modules get loaded and need to be initialized for no "apparent" reason. And that's not a fault of rumpkernels but NetBSD's twisted maze of module dependencies. > It's sort of reasonable to assume the following would work: here's > an image, can some file system driver handle it and with what sort > of capabilities (e.g. r/o) -- part of (or sideeffect of) Arnaud's > 2009 Summer of Code work was in converting mount() to probe() + > mount(), too bad it never got integrated. I didn't know he tried to make that work. > Anyway, if you're not interested in performance at all, either > dlopen() everything before rump_init() or just link them into > fs-utils. Not concerned much at the moment. One of the bridges I may or may not make it to in the future. :-) > I can't remember why it's restricted to "cold". Perhaps I was just > being overly cautious, or because I couldn't figure out how you > should access the list, nor how it would fit in the with the > existing interface, and neither was something that I was interested > in figuring out at the time. I could easily imagine being cautions and the problem never really surfacing with buildrump.sh, rumpctrl and rumprun. > Plus, I don't know if you should > synchronize. Maybe you could even enter the rump kernel -- the ctor > code runs without a rump kernel context -- and get the module loaded > immediately. However, I'm always a bit weary of calling things from > an unknown context; I guess we don't really know what type of > arrangement calls the ctor code on all possible platforms. Also, > then I don't know how to unload a module gracefully, since if the > only way to "test" unloading a module is calling dlclose(), you run > into problems if the module is busy. pgoyette@ did a lot of work on the module system recently. Mostly about autoloading and -unloading compat_xxx modules. It works much better these days then about 2 years ago. Proper refcounting and all that. The current feeling seems to be that auto-unloading isn't the bee'ss knees, though. > If you plan to put things on the list !cold, also maybe rename the > chain to something that doesn't contain "boot". Yeah. > >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. > > [...] > > You'd still have to change the module loading interface, but making > an interface work for one approach is easier than making it work for > two almost entirely different approaches. One idea that briefly surfaced was to make rump_pub_module_init() ignore its arguments in the CTOR case and process what is on the modinfo_boot_chain instead. I let it sink back again but it's circling beneath the surface. It's kinda muddy and unclean. But maybe not totally disgusting. It would still require to delete the "if (mi_start && mi_end)" boilerplate in potential users. I'll be watching the waters a while longer and see what else might bite. > Any potential users would need a flag day, but if you're updating > src-netbsd, I'm quite sure they're going to have a flag day > regardless. I'm not sure how many users there are that load components after rump_init(). Going by the mailing list that seems to be only me. :-) Actually so far the changes were very small for 3+ years of development on the NetBSD side. Most of the time was consumed in finding out by trial builds what else needs to be included and what needed updating in lower levels and in what files those bits lived. > >>behind a "debug-me" flag. > >Yeah. Or possibly even a "verbose" flag. > Oh we're discussing naming now? I'll prepare for a long thread ... Nah, not naming. It was more the difference between "I want to see what it is doing" and "something broke, I must see what it is doing at a level that is useful for debugging." Like the difference between aprint_verbose() and aprint_debug(). --chris
