On 04/13/14 02:55, Gabriel L. Somlo wrote: > Kevin, > > Thanks for the comments. I'll work your feedback (and any other > feedback I get by early next week) into another iteration of smbios > patches for both SeaBIOS and QEMU. > > In the mean time, there's one remaining "big picture" design question: > > On Sat, Apr 12, 2014 at 11:56:08AM -0400, Kevin O'Connor wrote: >> QEMU currently has command-line options that can modify the fields of >> the type0 tables (-smbios type=0,vendor='foo'). To continue to >> support that, I think QEMU should be able to build the type0 table as >> it feels fit to, and SeaBIOS should be able to pass it through. Of >> course, if there's no specific request from the end user, then I think >> QEMU can tell SeaBIOS that it may replace the type0 content with its >> own data (eg, via "etc/update-smbios-type0"). >> >> [...] >> >> As a minor quibble, I think patch 18 should make type0 required >> instead of optional (once there are the new fw_cfg entries there is no >> harm in always producing type0). Also, it would be nice to move up >> patch 18 to after patch 10 - that way an end-to-end test between >> old/new smbios with the new interface could be done. I defer to >> regular qemu developers on these comments though. > > There's three options I can think of: > > 1. QEMU always generates its own type 0 table. In this case, SeaBIOS > can probably just use that, along with the rest of the tables, as > provided. QEMU would have to "impersonate" or "channel" SeaBIOS when > generating the type 0 table (or "channel" TianoCore, depending on which > bios is being used). > > 2. QEMU only generates type 0 if explicitly told to do so on the > command line (i.e., *not* by default). In this case, SeaBIOS (or OVMF, > or any other BIOS) would have to scan the tables and insert its own > default type 0 if one was not purposely supplied by QEMU. (I know my > current SeaBIOS patch always overrides type 0, and agree that's > inconsistent with this option, and plan on fixing it :) > > 3. QEMU never generates a type 0 structure (i.e. we remove that > command line option), and the BIOS is *always* responsible for > generating it ("allowing type 0 on the qemu command line was a bad > idea, nobody uses it, we shouldn't have done it in the first place", > to paraphrase from an earlier thread). > > > I personally like #2 as it appears simple and flexible, and doesn't > require any further coordination (beyond qemu providing an entry > point and a set of tables). > > However, I'm not religious about it -- I'm only really after type 2 > and 17, for OS X's sake, as you all may remember... :) > > Gerd, Laszlo, what do you guys think ?
You're moving too fast for me. I'm swamped. By the time I'd come around reading and *maybe* answering your email, you make so much progress that you send three others :) So, I'll defer to y'all's good judgement. (I don't let my sense of taste get in my way any longer (and actually I don't want *others'* taste get in my way either, for that matter, when I'm the one posting patches...), so just make something simple and bug-free, document the format, and I'll adapt.) Thanks! Laszlo