Page MenuHomeFreeBSD

stand: libefi: swap /Pci() printing around
ClosedPublic

Authored by kevans on Mar 12 2022, 5:26 AM.
Tags
None
Referenced Files
F102444354: D34539.diff
Tue, Nov 12, 9:15 AM
Unknown Object (File)
Thu, Nov 7, 9:54 PM
Unknown Object (File)
Thu, Oct 31, 4:22 PM
Unknown Object (File)
Thu, Oct 17, 11:46 AM
Unknown Object (File)
Wed, Oct 16, 1:33 PM
Unknown Object (File)
Sun, Oct 13, 5:00 PM
Unknown Object (File)
Oct 13 2024, 7:54 AM
Unknown Object (File)
Oct 11 2024, 3:42 PM
Subscribers

Details

Summary

Printing device followed by interface matches, e.g., edk2.

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 44751
Build 41639: arc lint + arc unit

Event Timeline

This revision is now accepted and ready to land.Mar 12 2022, 5:28 AM

So why do we even use this function at all?

I mean, the change is right, but it's wrong that we use this function still anywhere at all. We should be calling back to UEFI to format this...

In D34539#782498, @imp wrote:

So why do we even use this function at all?

I mean, the change is right, but it's wrong that we use this function still anywhere at all. We should be calling back to UEFI to format this...

The firmware isn't guaranteed to provide the formatting protocol, so this is the fallback... working on a project right now where we actually exercise this path, and it caused me a couple of gray hairs.

This matches what I did in the UEFI wiring code and it matches the UEFI standard.

It looks like this is used only as a fallback...
And IIRC, this has been required since 2.0 and would only be wrong on things like old core/core2 macbooks.
Where is this failing?
And maybe we should look at what we do for libefi...

In D34539#782502, @imp wrote:

It looks like this is used only as a fallback...
And IIRC, this has been required since 2.0 and would only be wrong on things like old core/core2 macbooks.
Where is this failing?
And maybe we should look at what we do for libefi...

As of the 2.9 spec, table 2-11 in 2.6.1 does not list either the from/to text protocols as required elements. No objection to centralized handling if we do it elsewhere, too.

In D34539#782502, @imp wrote:

It looks like this is used only as a fallback...
And IIRC, this has been required since 2.0 and would only be wrong on things like old core/core2 macbooks.
Where is this failing?
And maybe we should look at what we do for libefi...

As of the 2.9 spec, table 2-11 in 2.6.1 does not list either the from/to text protocols as required elements. No objection to centralized handling if we do it elsewhere, too.

So it does...

I've held off on this in the past because I also entertained the idea of switching the EDK2 APIs so we can also pull in ACPI parsing...

In D34539#782504, @imp wrote:
In D34539#782502, @imp wrote:

It looks like this is used only as a fallback...
And IIRC, this has been required since 2.0 and would only be wrong on things like old core/core2 macbooks.
Where is this failing?
And maybe we should look at what we do for libefi...

As of the 2.9 spec, table 2-11 in 2.6.1 does not list either the from/to text protocols as required elements. No objection to centralized handling if we do it elsewhere, too.

So it does...

I've held off on this in the past because I also entertained the idea of switching the EDK2 APIs so we can also pull in ACPI parsing...

For us, the value is diagnostics - I did add those bits because there was some case about distinguishing those block devices...

This revision was automatically updated to reflect the committed changes.