On Wed, Jun 05, 2019 at 02:27:32PM +0900, AKASHI Takahiro wrote: > Tom, Wolfgang, > > On Wed, May 22, 2019 at 02:48:42PM +0900, AKASHI Takahiro wrote: > > Wolfgang, > > > > Thank you for your comments. > > > > On Fri, May 17, 2019 at 10:47:56AM +0200, Wolfgang Denk wrote: > > > Dear Akashi Takahiro, > > > > > > In message <20190517001206.gx11...@linaro.org> you wrote: > > > > > > > > > Who: usually the responsible custodians > > > > > > > > "Custodians" don't always mean sub-system maintainers. Right? > > > > > > It's just a different name for the same thing. > > > > Okay. > > > > > > In fact, I have already imported relevant kernel code into U-Boot > > > > and it now works perfectly with my experimental UEFI secure boot patch, > > > > but see the total size (and numbers) of files imported is quite big. > > > > I wonder who is willing to maintain them: > > > ... > > > > 37 files changed, 6409 insertions(+), 11 deletions(-) > > > > > > Well, if you compare for example against libressl-portable , then > > > this git repository has 180 files with more than 20,000 lines. > > > > I think that there are two different approaches in using > > external code (library). > > 1.import necessary source files into U-Boot repository, customize them > > and build them with the rest of U-Boot > > 2.build it as a static library, either totally outside of U-Boot > > or as a git submodule, and link it, i.e. only needed binary blobs, > > to U-Boot. > > (I don't know any existing libraries like this in U-Boot though.) > > > > We can adopt only (1) for kernel code, but *in general* (2) as well > > for a library. That way, we may potentially save/minimize our own > > maintenance cost, again *in general.* > > > > Those said, it seems to me that, gnutls, for instance, is not well > > optimized for smaller (or purpose-specific) systems. For example, > > _wrap_nettle_pk_verify(), public key verification function, supports > > not only RSA, but also DSA, ECDSA and so on with no "opt-out" options > > while UEFI secure boot only needs and supports RSA. > > > > > We are adding a lot of functionality, and anyone who wants to use > > > this will have to pay the price. But this is what I mentioned > > > before: I think the kernel code has already been tweaked with an > > > eye on resource consumption, while standard public libraries have > > > not. > > > > I'm not very sure about your last statement above, but as far as > > the customisability is concerned some libraries may have an issue > > in (2) as I mentioned above. > > > > In this sense, I still want to seek a possibility of using other > > smaller libraries, like mbedTLS. > > (mbedTLS has another issue, lacking pkcs7 parser.) > > > > > The kernel code may be big, but I would be surprised if there are > > > smaller and leaner alternatives with similar quality? > > > > > > As for who is willing to maintain it: I have no idea. Usually it > > > turns out to be the original implementoer / who pushed the code > > > upstream into U-Boot. > > > > Okay, but for most of examples you mentioned as linux-origin code, > > there are no explicit maintainers. Right? > > Do you have any further comments regarding maintainability? > (The *quality*, or trustworthiness, of the original code is > an orthogonal issue.)
No, I see it as a rather settled point that we leverage the linux kernel code as much as possible, when possible, as a rule of thumb even for the project. -- Tom
signature.asc
Description: PGP signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
