On 30/10/2019 00:13, Christoph Badura wrote:
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.
Thesis is more interesting than what, the updated book? Figures, v2.0
always sucks. I tried to delete the non-interesting irrelevant parts
during the update, but guess I managed the exact opposite.
BTW, thanks again for giving me a copy of the thesis!
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.
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.
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.
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.
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.
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.
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.
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.
It's less reasonable to assume the following would work: here's a random
string, throw everything you have at it.
Hence, I don't think networking file systems should be attempted unless
explicitly specified. And, by extension, networking doesn't need to be
loaded at all every time.
Anyway, if you're not interested in performance at all, either dlopen()
everything before rump_init() or just link them into fs-utils.
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.
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. 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.
^ more thinking out loud, in case that wasn't obvious
If you plan to put things on the list !cold, also maybe rename the chain
to something that doesn't contain "boot".
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.
Yes, it would be nice, but I can't figure out how to make it happen.
Some wisdoms from "hints for computer system design" may apply when
thinking about it.
One option would be to say that externally linked and loaded dynamic
modules always use ctors, and kill the GNU and sun ldscript options.
The ldscript=no option would of course remain for static linking. The
linksets were always such a pain to deal with in dynamic environments
that I wouldn't be sad to see them go. I guess I didn't kill dynamic
linksets when I added ctors because I didn't want to do an exhaustive
mental exercise of what might possibly break.
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. 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.
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 ...
