This patch adds (configurable) math/float support to libpayload.
The sources are taken from OpenBSD 4.6 and are either public domain or 3-clause BSD.
Also wrote a few new functions and moved some headers around to be able to compile libm sources unchanged.
Signed-off-by: Sylvain Ageneau sylvain_ageneau@yahoo.fr
--- Patch is big because it adds almost all of OpenBSD's libm sources: difficult to split it ...
Changes are quite extensive but should be harmless, I recompiled bayou and coreinfo and they still work fine.
I haven't tested on powerpc, if it breaks on that architecture it's still possible to configure libpayload to not use math functions. The x86 version uses asm sources whenever possible and other arches can use plain C sources.
I'll send another patch with tinyscheme.
Regards, Sylvain Ageneau
Am 05.02.2010 20:17, schrieb Sylvain Ageneau:
Patch is big because it adds almost all of OpenBSD's libm sources: difficult to split it ...
The OpenBSD code draws in some code that the GPL is incompatible with. Even if we drop all powerpc and amd64 code, there still remain two files with an advertisement clause. While OpenBSD tries to get rid of those, it seems that these files didn't make it yet. Same on the other BSDs (I checked them).
Then, there are design questions: this libm is made for userland, with a kernel expected to provide support if anything goes wrong. How does the math library cope with FPU exceptions? Does it at all?
There are also concerns of size (I didn't check, but the libm is easily as large as the rest of libpayload, incl. its drivers). I'm not worried too much about it, but maybe others are?
Design and size are something to discuss at least, the license issue is unfortunately still a deal breaker (but to a smaller scale than with dietlibc based functions), unless this can be reconciled somehow.
Regards, Patrick
On 2/7/10 5:29 PM, Patrick Georgi wrote:
Then, there are design questions: this libm is made for userland, with a kernel expected to provide support if anything goes wrong. How does the math library cope with FPU exceptions? Does it at all?
I have to second that
There are also concerns of size (I didn't check, but the libm is easily as large as the rest of libpayload, incl. its drivers). I'm not worried too much about it, but maybe others are?
It increases code size of libpayload roughly by a factor of five.. That's an incredible amount of code.
The code is unfortunately not quite clean and not really adapted to libpayload either. In fact, it looks like the BSD sources have mostly been just untarred in the libpayload directory.
A few checks show
- string.h provides functions like ffs() which is never defined - string.h provides prototypes for many functions that are still listed in libpayload.h, like memcpy, memcmp etc - none of the new includes have doxygen comments - the includes introduce many new and undocumented preprocessor flags, like __BSD_VISIBLE and __XPG_VISIBLE that might - ctype.h implements a whole bunch of functions in a .h file. - those functions already exist in ctype.c - lots of odd undocumented functionality like several setjmp implementations - mc68881 assembler versions of math functions?!? - man pages under libm/man? - source files under libm/src - rcsids? - patch to readline() breaks existing code out there - code introduces a couple of warnings with our reference toolchain, which will cause some payloads to break because they use -Werror.
Roughly I think that this approach of adding code to libpayload is not preferrable. It would be much nicer to see that those functions used by tinyscheme are chosen carefully, be added to libpayload in minimal implementations and commented in the same style we commented all the rest of libpayload.
Stefan
Am 07.02.2010 20:56, schrieb Stefan Reinauer:
It increases code size of libpayload roughly by a factor of five.. That's an incredible amount of code.
Ewww.
The code is unfortunately not quite clean and not really adapted to libpayload either. In fact, it looks like the BSD sources have mostly been just untarred in the libpayload directory.
A few checks show
Thanks for doing these.
- the includes introduce many new and undocumented preprocessor flags,
like __BSD_VISIBLE and __XPG_VISIBLE that might
Various degrees of standard compliance. Not sure if we need it.
- mc68881 assembler versions of math functions?!?
libpayload for palm pilot? *ducks*
- rcsids?
If we take code from a BSD wholesale, these are sensible to track upstream. That's how they do it among each other, so we can expect those ids to be correct.
Roughly I think that this approach of adding code to libpayload is not preferrable. It would be much nicer to see that those functions used by tinyscheme are chosen carefully, be added to libpayload in minimal implementations and commented in the same style we commented all the rest of libpayload.
Just to avoid any misunderstanding here: Code can still be imported from other sources, but not as a simple cp -R job.
Patrick
-
Patrick Georgi -
Stefan Reinauer -
Sylvain Ageneau