peter at stuge.se
Wed Sep 30 20:49:34 CEST 2009
ron minnich wrote:
> If libpayload can't fit seabios' needs then it needs to change so
> that it can.
Not so fast.
> It's not much of a library if seabios can't use it IMHO.
I disagree. libpayload is not optimized for a BIOS environment, and I
think that's a really good thing. But it does mean it's not a great
fit for SeaBIOS.
If libpayload becomes tailored to a single user, it's not much of a
> This may boil down to making the build process more flexible. I
> don't know.
That can be a good thing, but I don't know how helpful it is.
For memory allocation, maybe a variation on malloc in libpayload
could take a malloc context struct parameter which describes where
the area is located and has some callback hooks for when allocations
change so that a memory map can be updated if needed.
In the common case there will only be one malloc context. In SeaBIOS
Kevin said there are six. In FILO the area resize hooks are NULL and
never called, in SeaBIOS they can update the memory map.
Because SeaBIOS is a little special (nice way of saying partly 16bit)
it has special requirements. I think it would be very nice to reuse
source from libpayload, as well as open up the libpayload build
process if neccessary, if it is possible.
But I agree with Kevin that it needs to be worthwhile to actually go
and make changes both in SeaBIOS and in libpayload.
I also agree with Kevin that it doesn't really look like it is..
More information about the coreboot