From owner-svn-src-all@FreeBSD.ORG Mon Dec 7 14:33:39 2009 Return-Path: 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 505B91065672; Mon, 7 Dec 2009 14:33:39 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 0C9858FC14; Mon, 7 Dec 2009 14:33:38 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 0D2EF6D41B; Mon, 7 Dec 2009 14:33:38 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id D51B4844F2; Mon, 7 Dec 2009 15:33:37 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Luigi Rizzo References: <200912052009.nB5K9okL098577@svn.freebsd.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> <20091207133117.GA73597@onelab2.iet.unipi.it> Date: Mon, 07 Dec 2009 15:33:37 +0100 Message-ID: <86ocmavoou.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.95 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: svn-src-head@freebsd.org, Ed Schouten , svn-src-all@freebsd.org, src-committers@freebsd.org, Hajimu UMEMOTO 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 " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2009 14:33:39 -0000 Luigi Rizzo writes: > 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 Restoring sbuf_printf() to what it was would not change the API, but the semantics would be different in certain cases. The API would need to be extended to allow pseudofs to take full advantage of the changed semantics. (it is possible that the same functionality could be implemented in userland using funopen(3); such a solution would have all of the disadvantages of the current code except for the performance penalty, but none of its advantages) DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no