Daniel Kahn Gillmor <[email protected]> writes: > On 03/21/2011 03:04 PM, Niels Möller wrote:
>> One may want to think about fancy hardware accelerators (currently not >> supported at all), which would require some runtime check on what's >> available. > > that's an interesting part i hadn't considered. I'm not certain how to > represent such a change, but i like the idea that one could discover > available/supported hardware dynamically somehow. Would supporting that > use case suggest a different API? To add hardware acceleration, one would need to either detect hardware and build a list automatically at loadtime, or have a function to build and return the list. It can no longer be a compile-time constant. But I think the API you suggested is good enough for now. It's hard to guess what really interface is needed before the hardware support exists, and I'd rather not define something overly complicated just because it might possibly be needed later. >> Also, I think there should be one compilation unit and object file per >> list, so that it's, for example, possible to statically link with the >> list of all hash algorithms without also dragging in all ciphers. > Is there any reason to use this approach for statically-linked tools? The general principle is that independent functionality should be in separate object files. I don't think this case is an exception. To be a little more concrete, say you want a tool that can compute a hash sum using any algorithm supported by nettle, and you then want that tool on some constrained system with statically linked binaries, or included in a statically linked busybox executable. > Do you want me to submit a modified patch with these changes? That would be nice. Documentation would also be appreciated (it should probably mention why des is not on the list, but I don't think it needs to be terribly many words). Test cases are perhaps not essential for this, but maybe you can think of some relevant test? It may also be good to review the naming. Until now, the name attribute in nettle_cipher and similar structs has been intended to be displayed for informational purposes only. With your interface, users will be invited to use it as an identifier to look up an algorithm. How do you intend to use that name in the perl bindings? Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. _______________________________________________ nettle-bugs mailing list [email protected] http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
