Re: Config NO_BOOTMEM breaks my amd64 box

[Johannes Weiner]

On Thu, Apr 01, 2010 at 12:56:58AM +0200, Ingo Molnar wrote:
> I think what we want is your lmb series, with CONFIG_NO_BOOTMEM eliminated 
> altogether and x86 converted to pure (extended) lmb facilities, and without 
> any traces of bootmem left in x86.

That does not make much sense as bootmem is not only used on the architecture
side but also in generic code.  So you either have to emulate the API on x86
or get lmb in a state to replace bootmem on _all_ architectures.

> I.e. a really clean series with no CONFIG_NO_BOOTMEM kind of #ifdef crap left 
> around. This means 'nobootmem.c' (albeit saner than an #ifdef jungle) would be 
> moot as well.
> 
> We tried the dual model as it seemed prudent from a testing/conversion POV 
> (and it certainly allowed people to turn the new code off), but it's rather 
> ugly and we still have bugs left.

I think this was an implementation thing rather than a problem with the model
per se.

As written above, you can hardly get away without emulating the bootmem API
during transition.

> This means that if Linus likes that approach the conversion will be very 
> binary and very painful. The other option would be to go back to bootmem and 
> forget about the whole nobootmem and lmb thing.

I suppose it would be safest to replace early_res with lmb first to get
in sync with the other archs using it.

Step two would be to extend LMB and implement a bootmem emulation API on
top of it so that architectures can switch over to non-bootmem mode one
by one.  Then you can drop the real bootmem code and switch generic code
to use LMB natively, also site by site.  And finally, drop the emulation API.

If other architectures object to removing bootmem, there really is no point
for x86 to even try it.

For step one to work out, it's probably easiest to fully revert to the
.33 state than having to replace early_res while in its current state?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/