re: Time to merge the pgoyette-compat branch (take two)

[matthew green <mrg%eterna.com.au@localhost>]

> The original change from .a -> .o was made by maxv, in order to avoid
> having to determine where a couple of support objects were needed, and
> to avoid having to determine if there were any other such objects.  By
> changing from .a to .o method, maxv simply ensured that these support
> objects were always included in the kernel.  Unfortunately, that meant
> that _everything_ in the library was included, whether or not needed
> (based on the COMPAT_xx options present).

again, without looking too closely, i think the ultimate problem
here is that libcompat in the kernel is the wrong design, and it
should not be a kernel library.

it is probably this way to ease maintenance of other lists, since
what depends upon what code is fairly interdependant, and if you
just shove all the code in a library and link it, the stuff you
need is there, and the stuff you need isn't.

but really, all the code that depends upon other code should be
listed more explicitly, so that config/make can deal with it
instead of leaving it for the linker.  christos?  can you think
of any other/better ways to avoid this?  i think the only real
answer is to abandon kernel libcompat as-is.

Paul, i 100% agree this isn't a new problem. but your branch has
pushed it back into the foreground again :-)


.mrg.