From owner-freebsd-arch@FreeBSD.ORG Wed Sep 8 17:51:47 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A3DAB1065672 for ; Wed, 8 Sep 2010 17:51:47 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 52AD68FC1F for ; Wed, 8 Sep 2010 17:51:47 +0000 (UTC) Received: by yxn35 with SMTP id 35so208204yxn.13 for ; Wed, 08 Sep 2010 10:51:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=2WuaiYypXy03EVItJLWZCSguKSbB630SKEWLkF7Za54=; b=ekaMSNYg7xuMthEE8lH1gmrpAq15eY1CEgmFzopIqNpQ+bM03HzS583P5WmpQDU6lp /xDrIS32YOce+sNw/I++o/Wud4Dvt7Z/nYsgc0BXIa2qa73br1EbubS8iBzaTvuOfIhi C0uzNBopYTXd3/zkWLLpJGtfZAdpq1JsEfsE0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=h/qVmz6SmmTqYWI6HyRQcCU66eZ+zAvEHE+qprRJ+P/1UOr2dVWRvYtXvAV89xKfPC O4kVZKZukCD34Gx/xEnQk0tyPDTXrek6JWgPslaCxAlipT7w0iPM+OfzK231jKNg65n1 hxcgePjHKYTE1duJoBLJsh25btYw46/Sq/EOc= MIME-Version: 1.0 Received: by 10.101.193.5 with SMTP id v5mr266148anp.201.1283968306073; Wed, 08 Sep 2010 10:51:46 -0700 (PDT) Sender: mdf356@gmail.com Received: by 10.100.126.20 with HTTP; Wed, 8 Sep 2010 10:51:45 -0700 (PDT) In-Reply-To: <67448.1283967522@critter.freebsd.dk> References: <67448.1283967522@critter.freebsd.dk> Date: Wed, 8 Sep 2010 10:51:45 -0700 X-Google-Sender-Auth: ojjmNmhjWyVyUJFvbtQn4Y27Fa4 Message-ID: From: mdf@FreeBSD.org To: Poul-Henning Kamp Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Arch Subject: Re: Extending sbufs with a drain X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Sep 2010 17:51:47 -0000 Adding info to the quasi-digression: > I don't think an OTP is possible without compiler and language > support, and since the ISO-C people seems to have evaded this desire > to the full extent of their ability, it is probably never going > to happen in the C language. > > For one thing a OTP would allow you to define type specific formatters, > sort of the way the chapter 1. example in any C++ book teaches with > the << operator. =A0But this would require passing not only the varargs > but also their types to the formatting function. One other thing we have at Isilon that I would like to find some way to add to FreeBSD is the generic printf specifier. We added support in gcc for a %{} printf specifier which takes a struct fmt_conv_ctx: /** One of these gets passed to fmt_print for each %{}. */ struct fmt_conv_ctx { fmt_conv_func func; union fmt_conv_arg arg; }; where the fmt_conv_func is: /** Specifies the type of format conversion function. */ typedef void (*fmt_conv_func)(struct fmt *, const struct fmt_conv_args *, union fmt_conv_arg); and the fmt_conv_arg is a union of 2 uint64s, 2 pointers, 2 ints, a pointer and size_t, etc., etc. I.e. a generic blob that can hold a little data, or a pointer to a big thing. The fmt_conv_args has the bits indicating all the format modifiers like precision, left justification, etc., and also any string that appeared between { and }. Then when fmt_printf sees the %{} format it calls the function to add to the current struct fmt. Since it's unknown how long the %{} format data may end up being (and in fact a specifier to print a struct may use %{} on various members), there's a need for expanding the buffer or draining it. This is the glorious part 2, but I can easily see there's a *lot* of room for architecting a better solution. This is just what we have in house. > As I said, I agree about the usefulness, and with a API that fits > the sbuf design, I can probably be persuaded. > > But I will always have this nagging doubt that we just added yet > another deadbeat extension, rather than actually solve the > actual problem. So just to clarify, what do you consider the actual problem? I can say for sure that we have a lot of internal uses of out struct fmt (the thing we rolled before sbuf existed, that either grows or drains depending on initialization). There's a fine-grained leveled logging system, our ASSERT macro uses it. We use fmt_print() for all our sysctl handlers that deal with outputting text. The only things that don't anymore internally are the original printf(), panic() and KASSERT, and our code base has not added any more uses of those since it doesn't have the various print formatters we wanted. If preferred, I can start with a patch that adds %{} support to kernel and user printf implementations, but as I say the interface we use internally may not be preferred. Thanks, matthew