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 library either.
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..
//Peter