[coreboot] mkelfimage intelligent placement of ramdisk

[Jordan Crouse]

On 11/06/08 12:37 +0200, Peter Stuge wrote:
> On Tue, Jun 10, 2008 at 10:27:19PM -0700, H. Peter Anvin wrote:
> > APIs exist to decouple modules.  Use them.  I understand there is
> > finally some serious work going on in that vein in the coreboot
> > community; this makes sense.
> > 
> > The "no API" model is idiotic.
> 
> You don't feel it is possible/desirable to have all hardware code
> in the operating system so that boot code can be oneshot?
> 
> (of course the boot code still has to hand over state information)
> 
> What would the ideal abstraction be then?

Interestingly enough, this thread is intertwining with the "coreboot
BIOSisms" threat, and Peter has gotten his wish.. "Of course, as mere
producers we don't care too much, it would be interesting to discuss
also with the consumers".  Well, here is the owner of the init code 
for the only operating system we can boot.  I think he qualifies as
an interested party.

I don't presume to speak for hpa, but I do think I feel his concern.
His areas of interest aren't so very much different then ours.  With
syslinux and the kernel init code, his main goal is to take a decidedly
complex architecture and beat it into sanity.  And for the most part,
it will just work on any given x86 architecture - hpa isn't running around
trying Linux on every new platform that is coming out - he trusts that
the BIOS will give him the information that he needs.

Now, you can argue that that the API is old and archaic and stupid.
Those are legitimate arguments, but they aren't interesting for the guy
who doesn't want to have to worry about changing his code every time a 
BIOS software developer thinks he has something clever. 

This is a problem we are already struggling with.  Why doesn't gPXE work
out of the box?  Why wouldn't libpayload + coreinfo work on non coreboot
BIOSen (by all accounts it should).  The first answer is because we need
to add coreboot specific code to gPXE, and the second answer is that
we have _only_ coreboot specific code in libpayload.  These are probably
not optimal solutions.

Now, I don't know how hpa feels about the traditional BIOS API - perhaps he
too would be open to a new way of doing things.  But even if he is, there are
lots of API consumers right behind him (ACPI, mptable, etc, etc) that would
need convincing as well.  Its a long road to travel, and we may never
reach the end successfully.  I think what Kevin is doing is exactly the
right course of action - we need to play well with others, sooner rather
then later and then slowly bring them along with us.   That is the only
way we can be successful.  Storming in and saying "we are clever, support
us or die!" is not a great way to win over the world.

I'll leave you with a thought - the first guy who stood up and said
"Hey lets overthrow the king" got his head cut off.  It takes
consensus to make permanent change.

Jordan

-- 
Jordan Crouse
Systems Software Development Engineer 
Advanced Micro Devices, Inc.