#2569 May a package require ISA extensions (e.g., AVX-512)?
Closed: Accepted 3 years ago by churchyard. Opened 3 years ago by music.

I was considering reviewing https://bugzilla.redhat.com/show_bug.cgi?id=1881482 (intel-ipp-crypto-mb - Intel(R) IPP Cryptography multi-buffer library).

This library exists specifically to provide high-performance cryptographic primitives for systems with AVX-512 SIMD extensions. It does not have generic fallback code; the intent, I think, is that programs desiring fallback would just use OpenSSL or similar. As such, it is not only ExclusiveArch: x86_64 (OK with justification and tracker bugs), but the tests cannot be executed on most x86_64 systems, and it cannot be used on most x86_64 systems. However, it would be perfectly fine, practically speaking, for it to be linked by an application that used runtime CPU detection and fell back to OpenSSL when the necessary extensions were not available.

I have not seen a policy for whether software which, due to fundamental design, requires extensions to the base architecture can be packaged in Fedora. It seems this will be more and more common as people design dedicated software around wider and more flexible SIMD instructions. An opinion on this issue would be much appreciated.

Escalated from FPC: https://pagure.io/packaging-committee/issue/1044


From my perspective, this is little different from packaging a support application for a specific hardware device. If you don't have access to the appropriate hardware, the package is not useful to you.

The real question is how far we let such things go. I think I'd want there to be a rule that any application on the system must work on all officially supported hardware. Thus, such applications must either provide a fallback implementation OR cleanly exit when the requisite hardware is unavailable.

The submitter of intel-ipp-crypto-mb has politely corrected me, indicating that I missed the CPU dispatch functionality in this particular library, and there are not any general-purpose tests. This question therefore does not apply to that review.

I still appreciate the feedback, as I expect to encounter similar situations in the future and it is valuable to have an opinion on the record.

Let's close this then.

Metadata Update from @zbyszek:
- Issue close_status updated to: Invalid
- Issue status updated to: Closed (was: Open)

3 years ago

Why don't we record a decision instead for future use?

OK. Do you have a proposal for the text?

Metadata Update from @zbyszek:
- Issue status updated to: Open (was: Closed)

3 years ago

Libraries packaged in Fedora may require ISA extensions, however any packaged application must work on all officially supported hardware. Thus, such applications must either provide a fallback implementation OR cleanly exit when the requisite hardware is unavailable.

Isn't must work and either provide a fallback implementation OR cleanly exit contradictory? If an application just exits cleanly when ISA extensions are not available, it clearly does not "work" in the traditional sense.

I would just drop the "must work" requirement, or replace it with "must not crash", something like:

Libraries packaged in Fedora may require ISA extensions, however any packaged application must not crash on any officially supported architecture, either by providing a generic fallback implementation OR by cleanly exiting when the requisite hardware support is unavailable.

Yeah, @decathorpe's version is better. I move my +1 over to that.

APPROVED (+6,0,-0)

Where to document this?

Metadata Update from @churchyard:
- Issue tagged with: pending announcement

3 years ago

Metadata Update from @churchyard:
- Issue untagged with: pending announcement

3 years ago

Metadata Update from @churchyard:
- Issue tagged with: document it

3 years ago

Isn't this ticket enough of documentation by itself? If the subject comes up, just link to https://pagure.io/fesco/issue/2569#comment-713002.

I'm worried about low discoverability. But yeah, technically it is enough, especially if we don't have a place to document this.

We could make a pull request for the Packaging Guidelines…

OK, that solves it: I've reopened https://pagure.io/packaging-committee/issue/1044

Metadata Update from @churchyard:
- Issue close_status updated to: Accepted
- Issue status updated to: Closed (was: Open)

3 years ago

Login to comment on this ticket.

Metadata