This is wrong. Specifically is the MI <=> MD interface whereas is the x86 assembly-language <=> C interface. Mixing the two together would be bad.

Why are you proposing this? The function isn't declared in a header since the assembler doesn't understand those. If you were thinking of calling from C that is almost certainly a Bad Idea. The function which needs to be called is , but that function must conform to the interface (since it needs to be MI and be called as a driver-filter).

Are you perhaps aiming to merge all the assembly-language <=> C bridges? You might want to look at Github #1748. It appears 's interface originated on x86 with minimal variation between PICs and cascading PICs being rare (aside from the pair of 8250s, but those are handled by the same driver). Whereas the moment cascading PICs appear 's interface really needs fixing.

In D56005#1281266, @ehem_freebsd_m5p.com wrote:

This is wrong. Specifically is the MI <=> MD interface whereas is the x86 assembly-language <=> C interface. Mixing the two together would be bad.

It is C function, it can be called from C. What is the problem?

Why are you proposing this? The function isn't declared in a header since the assembler doesn't understand those. If you were thinking of calling from C that is almost certainly a Bad Idea. The function which needs to be called is , but that function must conform to the interface (since it needs to be MI and be called as a driver-filter).

D55829

Are you perhaps aiming to merge all the assembly-language <=> C bridges? You might want to look at Github #1748. It appears 's interface originated on x86 with minimal variation between PICs and cascading PICs being rare (aside from the pair of 8250s, but those are handled by the same driver). Whereas the moment cascading PICs appear 's interface really needs fixing.

In D56005#1281270, @kib wrote:

In D56005#1281266, @ehem_freebsd_m5p.com wrote:

This is wrong. Specifically is the MI <=> MD interface whereas is the x86 assembly-language <=> C interface. Mixing the two together would be bad.

It is C function, it can be called from C. What is the problem?

This is the wrong header to have that in. Most of the headers are at least semi-private so anything outside of the Xen interface shouldn't be including them. I'm unsure of the proper place to put such a declaration, but is certainly wrong. Since this isn't used internally by the Xen interface the two headers I notice are and . Since this is a semi-internal PIC function almost seems the best of those.

Move the proto to apicvar.h.

This is still a distortion, but far less of one than having it in . Naturally this means header adjustment elsewhere.

It might be easier if I just switch Xen to use like mentioned in the other review. That would prevent more Xen stuff leaking into generic headers which is not specially nice.

In D56005#1281766, @royger wrote:

It might be easier if I just switch Xen to use like mentioned in the other review. That would prevent more Xen stuff leaking into generic headers which is not specially nice.

I agree, please do.