On Thu, Sep 03, 2015 at 07:33:17PM +0300, Michael Tokarev wrote: > 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
Yes, we want that cleaned up.
