On 2016-02-09 at 19:16 Dan Cross <[email protected]> wrote: > / $ ls \#acpi > > APIC FACP HPET SSDT pretty raw table > > > > Is the APIC the MADT? > > > > It is. Logical, isn't it? That's inherited from Plan 9.
I briefly looked into changing it. It's actually from ACPI itself. The signature from the table is "APIC", which we match for our ptable[] parsing. The ACPI spec calls it the MADT (5.2.12), but they picked APIC as the signature for the table. Ridiculous. We can change it, but it'll require not using the table's signature as its name. > > > +#define ATABLEBUFSZ ROUNDUP(sizeof(struct Atable), 16) > > > > Is this based on the assumption that anything a caller of mkatable > > wants to add to Atable->tbl will need to be at most 16 bytes > > aligned? (since mkatable() does the allocation for its caller for > > t->tbl). > > > > Yes. I believe that's the guarantee malloc() makes in the C standard > (don't quite me on that). Cool. We don't use malloc(), but we happen to have the same guarantee with our kmalloc. I'll change that 16 to KMALLOC_ALIGNMENT. Btw, this doesn't detect the DMAR on my desktop. But I hear it's working on other similar machines. Maybe my desktop is just weird or is misconfigured. Merged to master at aa8ba52e5e9f..3c10f8d712b0 (from, to] You can see the entire diff with 'git diff' or at https://github.com/brho/akaros/compare/aa8ba52e5e9f...3c10f8d712b0 Barret -- You received this message because you are subscribed to the Google Groups "Akaros" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. For more options, visit https://groups.google.com/d/optout.
