On Mon, Apr 13, 2015 at 11:34:49AM -0500, Corey Minyard wrote: > On 04/13/2015 02:00 AM, Michael S. Tsirkin wrote: > > On Sun, Apr 12, 2015 at 08:26:46PM -0500, Corey Minyard wrote: > >> On 04/12/2015 11:05 AM, Michael S. Tsirkin wrote: > >>> On Tue, Apr 07, 2015 at 02:51:39PM -0500, miny...@acm.org wrote: > >>>> From: Corey Minyard <cminy...@mvista.com> > >>>> > >>>> There was no way to directly add a table entry to the SMBIOS table, > >>>> even though the BIOS supports this. So add a function to do this. > >>>> This is in preparation for the IPMI handler adding it's SMBIOS table > >>>> entry. > >>>> > >>>> Signed-off-by: Corey Minyard <cminy...@mvista.com> > >>> Do we have to use a callback for this? > >>> > >>> It seems that if smbios_table_entry_add just added the table > >>> itself to some array or a linked list, then devices could just call > >>> smbios_table_entry_add instead of registering a handler. > >>> > >>> And smbios_get_tables would scan that and get the tables. > >> Well, there are many ways you could handle this, and it doesn't seem > >> much different in the end to me. You either have a list of items to add > >> to the table or a list of callbacks to fill in the data. > >> > >> I made this the same as the ACPI code, which you have to have as a > >> callback if you are adding it to a common SSDT. > > Not really I think. > > The AML functions require that you have a tree to attach what you are > adding. If you did your own SSDT, you wouldn't need a callback. You > could add a binary blob that gets put into the SSDT, but I think that > would require adding some AML functions.
Oh, you are using functions from aml-build.c. I forgot that they can only be used within ssdt ATM. Maybe that's worth fixing. I need to ponder this a bit. -- MST
