Should this be usable without allocator_api?

[A0lson]

I initially attempted to use the acpi crate on a no_std system...

However, I found it is difficult to use (especially the master branch without the allocator_api feature being enabled.

Aside from a minor compile error, many of the table structs have all private fields and only seem usable by the allocator_api enabled code. (At least my initial interest was the MCFG and MADT tables).

Would there be any appetite for making all the low-level structs have public fields? Or is there some other design goal that I'm not aware of?

[IsaacWoods]

Hi, glad to hear you've tried the library out.

The refactor to the new allocator API was relatively recent and has not been pushed over the line in a form that is yet completely usable. There would definitely be appetite for making this possible, and if that requires making all the raw structures public then so be it - feel free to get something working in a fork and submitting a PR :)

Design wise, most users will still find it most useful to have an allocator available, and to let the library allocate freely and provide higher-level data structures. This is not yet easily done on main, so it might be better to use a released crates.io version for the time being, until I have time to polish main off. It's very typical to still provide heap allocation in a no_std context, but some people are interested in either not doing that, or making heap allocation fallable, hence the new direction.

Hopefully that answers some questions - lmk if not and if you've found any other pain points in using the libraries.