Current-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

The rump library mess - can it be fixed?



I believe it would be a good idea to do away with all but one (probably,
there might be good reasons for keeping one or two more) of the rump
libraries, and concentrate (almost) everything into -lrump

I see no paritcular benefit in keeping the myriad (seems like
thousands to me ... but probably isn't quite that many) different
rump libraries around - linking all of the needed ones has to be
wasting a bunch of time, and I can't see how there's any notable
benefit to not having all of them loaded in any practical cases.
Often they're all loaded by one process or another (so they're
all in mem anyway - just not necessarily all in any single process's
address space).

For static linking it can only be an improvement - each application
gets the entries from the library (or libraries now) that it needs,
it will end up with the exact same ones, but does that in one link step
rather than reading (and in some cases, re-reading) the .a files over
and over again to satisfy one more dependency needed by one of the
other libraries.

For dynamic linking, the startup cost has to be smaller, to link
just one library, rather than 6 or 12 of them.

But none of that really matters, and whatever saving exists there
wouldn't be worth the cost of changing things - if it weren't for
the incredible maintenance mess we're in at the minute.   Every time
something changes, particularly in the kernel, but other changes
sometmes matter, it is likely that rump linking fails, and someone
has to work out just what bizarre combination of libraries in which
order, is needed to make things work again.

So, what I'd propose is that we merge everything into one, or perhaps
2 libraries (I haven't looked at the details yet, I suspect one will be
enough, but it is possible things will work better with more than one,
but certainly a very small number, with no interactions between them)
and "do away" with all the others.

To accomodate existing dynamic linked binaries that want to link all
the various libraries that currently exist, I'd suggest making dummy
libraries, which export nothing and reference nothing (unless the former
is not allowed, in which case I'd give them a single function with a
name like "using_librumpXXX_is_no_longer_required_use_just_librump_instead")
(which would be implemented as:
	 void using...instead(void) { }
).

Does anyone know of any reason that would not work?   Or have any objections
to moving in that direction?    (After NetBSD-9 is branched).

kre



Home | Main Index | Thread Index | Old Index