-----Original Message----- From: Jordan Crouse [mailto:jordan.crouse@amd.com] Sent: Monday, June 02, 2008 5:48 PM To: Myles Watson Cc: 'ron minnich'; coreboot@coreboot.org Subject: Re: LinuxTag 2008 Status
On 30/05/08 16:59 -0600, Myles Watson wrote:
But when you look closer, the number of possible modes explodes. As
an
example:
- You may want to add a timeout to the menu, so that if somebody
doesn't
press the hotkey, a default payload is chosen.
- When chaining, some payloads will be opt in (press F1 for setup),
some
will be opt out (press F2 to skip), and others will always run
- Uwe expressed a desire to select a chain from the menu
Everything is further complicated by the fact that we can add a new payload to the LAR at any time, which makes it very difficult to specific the configuration at bayou compile time.
How about the name of the lar entry for the payload (since we can store
the
user-friendly name in the notes.) The default payload is the one named "payload" or "normal" or "default". Then any number of payloads with
their
attributes can be added, but the default still works.
I like this, but allow me to play devil's advocate for a second. There might be a few flies in the ointment. The dynamic nature of LAR forces us to consider complex scenarios that otherwise wouldn't be a factor. What if you want to change the default payload? If the name isn't shorter then payloads/default, then there will be much shifting of bytes, which is dangerous on the ROM (or rather, no less dangerous then writing a new ROM).
Right now we don't do partial writes, do we? If we did, this isn't dangerous as long as we rewrite the entire lar entry, is it?
The other thing that concerns me is that the person building the LAR needs to make the conscious decision to name one of the payloads payload/default.
No matter what we choose to do, the user will have to make a conscious decision about which payload is default. If there isn't a default it will still work, and they'll be more careful next time they build the ROM. :)
Sure we could make the LAR binary handle the magic, but that would be just another flag in a cast of thousands. We already experience a bit of this pain already. In lieu of a magic number in the LAR header or in the SELF header, bayou currently checks for the name prefix 'payload/' and assumes that is a payload. I have already forgotten to append 'payload/' several times (until I got the Makefile to do it for me). I believe that this will cause problems down the road - not everybody will be using buildrom.
You're right, we still have considerable evangelism to do.
All that said, I think that this is the best suggestion so far - it is easy to implement, and at least gets us further down the path.
I'm looking forward to seeing the next incarnation.
Thanks, Myles