Identifying the bits relevant to openssl for each architecture and making them available through architecture-independent functions (getter and setters) would be very convenient, indeed. At the risk that future architectures do not fit into the pattern defined today.
If this approach is implemented, I suggest a copy of original capability vector to be kept, for the setter to fail if a bit is tentatively set on an unsuitable processor (otherwise, subsequent cryptographic operations affected by the bit in question would fail anyway). Thus a setter could return the previous value (0 or 1) on success, and -1 on failure. I think that implementing the architecture specific functions suggested in this ticket is easy and already useful. Defining architecture-independent functions probably requires more hard thinking, and could be done in a later step. ________________________________ From: Salz, Rich via RT <r...@openssl.org> Sent: Tuesday, June 14, 2016 6:41:02 PM To: Loic Etienne Cc: openssl-dev@openssl.org Subject: RE: [openssl-dev] [openssl.org #4568] Enhancement request: Capability vector accessor function for arm and ppc Doesn't it make more sense to have a single API that returns the platform-specific flags? -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4568 Please log in as guest with password guest if prompted -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4568 Please log in as guest with password guest if prompted -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
