[haiku-commits] Re: BRANCH waddlesplash-github.libroot-sha256 [e6a3dfe38b01] src/system/libroot/posix/crypt src/kits/shared headers/private/libroot src headers/private/shared
- From: Adrien Destugues <pulkomandy@xxxxxxxxxxxxx>
- To: haiku-commits@xxxxxxxxxxxxx
- Date: Tue, 3 Oct 2017 07:22:52 +0200
On Tue, Oct 03, 2017 at 12:00:48AM +0200, Axel Dörfler wrote:
Am 02/10/2017 um 19:46 schrieb Adrien Destugues:
- So, there is no point in putting the stuff in libshared if is already
is in libroot anyway.
Conclusion: let's be clear about what we mean, and if we need this code
in libroot, let's have it there.
Linking it into libroot via libshared does *not* mean it has to be exposed
in any way.
Not sure if we build it like this, but if that was our intention, we should
do so, instead of making it publicly available.
However, in this particular case, I wouldn't mind having that kind of
functionality built into some public API. So while the reasons are not
sound, I would even go one step further, and make it public (I haven't
looked at the API exactly, it would best be compatible to something already
out there).
It was public API in libshared, waddlsplash moved it to libroot but also
into BPrivate.
I think there were plans for a "crypto kit" in Haiku with a somewhat
larger set of classes, which may make more sense as a public API. But
we'll still need the low level SHA256 implementation in libroot, while
the crypto kit would be in libbe (or a separate lib). If that turns out
to be a problem, something similar to what we do for ICU implementing C
locale support would be needed (minimal implementation in libroot + ICU
taking over if available, through add-ons).
--
Adrien.
Other related posts: