03.09.2015 18:37, Laszlo Ersek wrote: [] > Actually, 6 + 4 + 4 = 14, so OemID and OemTableID. But, you are right, I > was working off the commit message & comments only, not the actual > amount of bytes copied. > > This ties down both OemID and OemTableId, between all of RSDT, SLIC, and > FADT. Since > - I argue against exposing a generic oem_table_id on the command > line (unlike oem_id), > - and I also find that an oem_table_id "map" would be overkill, > > I think it follows that I can only ask for the special SLIC-handling > logic already visible in your patch. "User passed in SLIC --> adapt RSDT > and FADT." That is, it is already user-controlled.
It might be useful to have it controllable by user in other cases too. But I don't have any usage case for that. > (The FADT change will ensure that OVMF will update the RSDT that *it* > installs.) > > This is just my preference, of course... But at least it doesn't seem to > conflict with Michael's! :) Yes, it might just work. Especially since in case when SLIC is specified, the oem_table&Co should come from SLIC, not forcing user to specify them on command line. Command line can be used anyway, with the default value coming from slic if it is provided. BTW, I updated the patch for 2.4 a few days ago, it is hackish as I wanted to touch as few files as possible. And BTW2, the code in acpi/core.c uses its own local definition of ACPI table data structures, instead of using common code from acpi.h... ;) Thanks, /mjt
