From owner-freebsd-arch Mon Feb 26 22:57:14 2001 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (flutter.freebsd.dk [212.242.40.147]) by hub.freebsd.org (Postfix) with ESMTP id BB76537B70D for ; Mon, 26 Feb 2001 22:57:11 -0800 (PST) (envelope-from phk@critter.freebsd.dk) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.1/8.11.1) with ESMTP id f1R6vHM26417; Tue, 27 Feb 2001 07:57:17 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Bruce Evans Cc: "Kenneth D. Merry" , arch@FreeBSD.ORG Subject: Re: sbufs in userland In-Reply-To: Your message of "Tue, 27 Feb 2001 17:16:27 +1100." Date: Tue, 27 Feb 2001 07:57:17 +0100 Message-ID: <26415.983257037@critter> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message , Bruce Ev ans writes: >So everyone agrees that sbufs are a mistake :-). The kernel should use >the same interfaces as userland for general things like printf() and >malloc() (oops, too late), if it needs such interfaces at all, so that >programmers can reuse their knowledge of userland. However, I doubt >that general string handling in the kernel is needed often enough to >justify having sbuf or funopen. No we dont argee on that. *if* the kernel can use the same API it should, but most often it can't. strlen() comes to mind as an API where it can't use it. In the kernel strlen should return an error code if it tries to access non-accessible memory, rather than core-dumping as it does in userland. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message