From owner-svn-src-all@FreeBSD.ORG  Mon Dec  7 13:22:58 2009
Return-Path: <owner-svn-src-all@FreeBSD.ORG>
Delivered-To: svn-src-all@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id E60F01065693;
	Mon,  7 Dec 2009 13:22:58 +0000 (UTC)
	(envelope-from luigi@onelab2.iet.unipi.it)
Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238])
	by mx1.freebsd.org (Postfix) with ESMTP id A4FAF8FC20;
	Mon,  7 Dec 2009 13:22:58 +0000 (UTC)
Received: by onelab2.iet.unipi.it (Postfix, from userid 275)
	id 3CF7273106; Mon,  7 Dec 2009 14:31:17 +0100 (CET)
Date: Mon, 7 Dec 2009 14:31:17 +0100
From: Luigi Rizzo <rizzo@iet.unipi.it>
To: Dag-Erling Sm??rgrav <des@des.no>
Message-ID: <20091207133117.GA73597@onelab2.iet.unipi.it>
References: <200912052009.nB5K9okL098577@svn.freebsd.org>
	<ygek4wzpdv3.wl%ume@mahoroba.org> <20091207055752.GD64905@hoeg.nl>
	<20091207085927.GC57764@onelab2.iet.unipi.it>
	<86iqcjt93c.fsf@ds4.des.no>
	<20091207105343.GA62012@onelab2.iet.unipi.it>
	<86ein7t5m5.fsf@ds4.des.no>
	<20091207130433.GA71902@onelab2.iet.unipi.it>
	<86skbnrkrz.fsf@ds4.des.no>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <86skbnrkrz.fsf@ds4.des.no>
User-Agent: Mutt/1.4.2.3i
Cc: svn-src-head@freebsd.org, Ed Schouten <ed@80386.nl>,
	svn-src-all@freebsd.org, src-committers@freebsd.org,
	Hajimu UMEMOTO <ume@freebsd.org>
Subject: Re: the need for safe dynamic string libraries
X-BeenThere: svn-src-all@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "SVN commit messages for the entire src tree \(except for &quot;
	user&quot; and &quot; projects&quot; \)" <svn-src-all.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/svn-src-all>,
	<mailto:svn-src-all-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/svn-src-all>
List-Post: <mailto:svn-src-all@freebsd.org>
List-Help: <mailto:svn-src-all-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/svn-src-all>,
	<mailto:svn-src-all-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Dec 2009 13:22:59 -0000

On Mon, Dec 07, 2009 at 02:11:44PM +0100, Dag-Erling Sm??rgrav wrote:
> Luigi Rizzo <rizzo@iet.unipi.it> writes:
> > "Dag-Erling Sm??rgrav" <des@des.no> writes:
> > > When libsbuf was ported to userland, sbuf_printf() was pessimized
> > > due to the limitations of libc's printf().
> > but, isn't this an implementation detail ? What prevents the same
> > API to have two different implementation, one for kernel, one for userland ?
> 
> Maybe I wasn't entirely clear: functionality was removed from libsbuf
> because it could not be implemented in userland, because our printf(3)
> is badly implemented.  To restore that functionality, we would have to
> either fork libsbuf or fix printf(3).

i think i understood correctly.
But my point is-- does the functionality that was removed rely
on a different API, or we can keep the same API and have two
different implementation of the hopefully few things that change
between kernel and userland

	int
	sbuf_printf(struct sbuf *s, const char *fmt, ...)
	{
		// common code
	#ifdef _KERNEL
		... the wonderful bits
	#else
		// crippled due to printf limitations
	#endif
		// more common code

This does not seem too problematic...