From owner-freebsd-hackers Thu Nov 14 20: 4:28 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8E92237B401 for ; Thu, 14 Nov 2002 20:04:26 -0800 (PST) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1222043E8A for ; Thu, 14 Nov 2002 20:04:26 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.12.5/8.12.5) with ESMTP id gAF44IFC073191; Thu, 14 Nov 2002 20:04:18 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.5/8.12.5/Submit) id gAF44IZ9073190; Thu, 14 Nov 2002 20:04:18 -0800 (PST) (envelope-from dillon) Date: Thu, 14 Nov 2002 20:04:18 -0800 (PST) From: Matthew Dillon Message-Id: <200211150404.gAF44IZ9073190@apollo.backplane.com> To: Peter Jeremy Cc: hackers@FreeBSD.ORG Subject: Re: cvs commit: src/bin/sleep sleep.c References: <200211132012.gADKCQxr062768@repoman.freebsd.org> <20021113204503.GI9006@vega.vega.com> <20021113.215346.90827277.imp@bsdimp.com> <200211142257.gAEMvdxX071776@apollo.backplane.com> <20021115032946.GP6446@gsmx07.alcatel.com.au> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG :> 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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message