You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It seems like there are sometimes both ACPI v1 and v2 RSDPs in memory: rust-osdev/bootloader#172 . Since we want to prioritize the v2 RSDP it would be great if the RSDP::search_for_on_bios function was able to return all available RSDPs, not just the first. This could be for example implemented by returning an Iterator from the function or by adding a start_offset parameter (perhaps in a separate function). Would you be open to a PR that implements something like this?
The text was updated successfully, but these errors were encountered:
Generally, my policy with ACPI is that we have to do whatever is required to support real implementations, since it's such a mess.
That being said, I don't understand why firmware would bother to keep two different RSDP structures in memory, since they are backwards compatible. If you get given a v2 RSDP, the first part of the structure contains a v1 one (see §5.2.5.3 of the spec), so a legacy ACPI implementation can still read a RSDT out of it. My reading of the spec also infers that there should really only be one (in contrast, it is completely fine to have a separate RSDT and XSDT, both pointed to at different addresses by the same RSDP).
Therefore, I'd like to first confirm that we really are seeing two different RSDPs, at two different addresses, and that they have differing contents (e.g. different revisions) (cc @gifnksm).
It seems like there are sometimes both ACPI v1 and v2 RSDPs in memory: rust-osdev/bootloader#172 . Since we want to prioritize the v2 RSDP it would be great if the
RSDP::search_for_on_bios
function was able to return all available RSDPs, not just the first. This could be for example implemented by returning anIterator
from the function or by adding astart_offset
parameter (perhaps in a separate function). Would you be open to a PR that implements something like this?The text was updated successfully, but these errors were encountered: