Date: Thu, 14 Nov 2002 20:04:18 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Peter Jeremy <peter.jeremy@alcatel.com.au> Cc: hackers@FreeBSD.ORG Subject: Re: cvs commit: src/bin/sleep sleep.c Message-ID: <200211150404.gAF44IZ9073190@apollo.backplane.com> References: <200211132012.gADKCQxr062768@repoman.freebsd.org> <Pine.BSF.4.44.0211131528010.32919-100000@niwun.pair.com> <20021113204503.GI9006@vega.vega.com> <20021113.215346.90827277.imp@bsdimp.com> <200211142257.gAEMvdxX071776@apollo.backplane.com> <20021115032946.GP6446@gsmx07.alcatel.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
:> borrowed from libc), sufficient for simple binaries. It could be made
:> compatible with our standard includes (structural bloat != code bloat,
:> so who cares).
:
:I think Nate's got a good point regarding maintainability here. If we
:do want to create a mini-libc, we need to minimise the amount of code
:duplication. Note that, based on a quick nm and size on libc.a, we
:could halve the size of printf() by undefining 'FLOATING_POINT' in
:vfprintf.c, with virtually no additional maintainability effort.
:
:(Xenix/286 used to have both integer-only and FP-aware variants of
:the standard libraries. The compiler would automatically select the
:libraries based on FP references in the code. Though I do recall
:managing to confuse it on one occasion).
:
:Peter
What I did in DICE was put a full FP-supporting printf core
in libm, and an integer-only printf core in libc. If you
added -lm to the link line you got the full printf, otherwise
you got the integer-only printf.
I don't think that's workable for FreeBSD, though, people just
expect FP in printf without libm these days, so it would still
make sense to create a mini-libc. It's unfortunate, but libc
has turned into a kitchen sink for just about everything.
I would not worry too much about duplicate code. It just isn't
a big issue. The whole idea of having a mini-libc is that it
would contain only a subset of features, as unfancy as possible.
This translates to very few bugs and virtually no additional
maintainance burden.
In regards to integrating a mini-libc with libstand... well,
that would be possible but to do it right would require
a radically different approach. In DICE I had a 'librom'
which was platform independant code (made no system calls,
just pure infrastructure functions like pfmt(), s*printf(),
strcpy(), etc...). I would approach a mini-libc and libstand
integration by creating a 'librom' equivalent, and then
having libstand extend it out and mini-libc (as a separate
entity) also extend it out. That would reduce code duplication
considerably yet still allow the libraries to focus on the
particular functions they were designed for.
-Matt
Matthew Dillon
<dillon@backplane.com>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200211150404.gAF44IZ9073190>