On Tue, Mar 31, 2020 at 04:53:02PM +0200, Gerd Hoffmann wrote:
> On Fri, Mar 27, 2020 at 09:15:19AM -0400, Kevin O'Connor wrote:
> > On Fri, Mar 27, 2020 at 09:12:06AM +0100, Gerd Hoffmann wrote:
> > > > Something like:
> > > > 
> > > > struct hlist_head DSDTTree;
> > > > 
> > > > struct dsdt_entry {
> > > >     struct hlist_node node;
> > > >     char *name;  // eg, "_SB.PCI0.ISA.COM1._HID"
> > > >     int type; // eg: Device, Name, Integer, String, ResourceTemplate, 
> > > > other
> > > >     void *value; // points to integer, string, resource template, or 
> > > > NULL
> > > > };
> > > > 
> > > > Once the tree is parsed, it should be simple to walk the in-memory
> > > > linked-list to find desired values later.
> > > 
> > > I was thinking more about storing a list of devices with parsed data,
> > > i.e. basically put into a linked list what the current code collects
> > > in the parse_dev struct.
> > 
> > FWIW, I suspect it will be painful to grow 'struct parse_dev' if there
> > are future users.  (For example, if there is more than one memory
> > range needed, if it is necessary to check for the existence of some
> > name other than _STA, etc. .)  In contrast, I suspect a few helper
> > functions that can walk the tree would be sufficient to extract the
> > info currently in 'struct parse_dev' as needed.
> 
> Went with a hybrid approach now.  parse_dev is still there, but for the
> most part part it stores pointers into the dsdt table and parsing
> happens later as needed.
> 
> sneak preview @ https://git.kraxel.org/cgit/seabios/log/?h=dsdt

Thanks.  FWIW, I think the code would be simpler if it first parsed
the tree into an internal structure, and then searched for _STA, _HID,
etc.  Attempting to do both at the same time seems to complicate the
code.

> > > Then we can easily lookup the virtio-mmio devices later.  Maybe also
> > > check for isa devices (don't bother waiting for ps2 probe timeout if
> > > acpi says there isn't a keyboard ...).  I don't see any other use
> > > cases.
> > 
> > It would be helpful to extract the location of builtin sdcards from
> > the dsdt (currently, the "etc/sdcard" cbfs file is used instead).
> 
> That'll be used with coreboot, right?  How do sdcard dsdt entries look
> like?

Yes, with coreboot.  I don't recall the details right now - perhaps
Matt or John recall?

-Kevin
_______________________________________________
SeaBIOS mailing list -- seabios@seabios.org
To unsubscribe send an email to seabios-le...@seabios.org

Reply via email to