From owner-freebsd-arch@FreeBSD.ORG Tue Sep 7 15:02:59 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 5901610656BA for ; Tue, 7 Sep 2010 15:02:59 +0000 (UTC) (envelope-from cherry@zyx.in) Received: from reagan.nswebhost.com (reagan.nswebhost.com [64.22.87.10]) by mx1.freebsd.org (Postfix) with ESMTP id 0936A8FC1D for ; Tue, 7 Sep 2010 15:02:58 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=zyx.in; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-Antivirus:X-Antivirus-Status; b=JKV4yOhRrb/zsT4ucKXdAVJPmcREz5OOUBloAy7YgtPGBun3twrNaATwUS4H+Q12OCfbKQgklSli/RTJLWfX/QUgOjr9A6G6uPmPb7RqKTTgIlqx2m1Lq+66A8bAWxQA; Received: from [59.93.16.111] (port=60608 helo=[127.0.0.1]) by reagan.nswebhost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1OszQI-0002gt-PO; Tue, 07 Sep 2010 09:45:24 -0500 Message-ID: <4C864FFD.6020409@zyx.in> Date: Tue, 07 Sep 2010 20:15:17 +0530 From: "Cherry G. Mathew" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.8) Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Alexander Motin , freebsd-arch@freebsd.org References: <4C0C1AE4.8050807@FreeBSD.org> In-Reply-To: <4C0C1AE4.8050807@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 100907-0, 09/07/2010), Outbound message X-Antivirus-Status: Clean X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - reagan.nswebhost.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - zyx.in X-Mailman-Approved-At: Tue, 07 Sep 2010 15:35:06 +0000 Cc: Subject: [resend] Re: RFC: New event timers infrastructure 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: Tue, 07 Sep 2010 15:02:59 -0000 Dear Alexander, On 6/6/2010 10:02 PM, Alexander Motin wrote: > > I did such things: > - created unified timer driver's API (sys/timeet.h, kernel/kern_et.c). > It supports global and per-CPU timers, periodic and one-shot. Provides > driver and consumer interfaces for choosing timers and operating them; [...] > Latest patches can be found here: > http://people.freebsd.org/~mav/et.20100606.patch > [...] > > Feedback is very appreciated. > Had you considered integrating this api with sys/timetc.h ? Most timer devices which can interrupt after a certain period of time, can also provide counters, I would imagine ? I'd be keen to know your thoughts on providing the ability of et consumers to daisy chain to a single eventtimer. It would be good for et_find() to query for timers that can guarantee a specific resolution/period or below/above. Finally, I'm curious to know what et_quality implies ? Perhaps it can be an indication of the max/min resolution/period available from a given et ? Many Thanks, -- cherry PS: please Cc: me too - I'm not on-list. From owner-freebsd-arch@FreeBSD.ORG Tue Sep 7 18:12:57 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 0E14B10656BE for ; Tue, 7 Sep 2010 18:12:57 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id C05CC8FC14 for ; Tue, 7 Sep 2010 18:12:56 +0000 (UTC) Received: by gxk24 with SMTP id 24so2403257gxk.13 for ; Tue, 07 Sep 2010 11:12:56 -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:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=lFW6ZDXwSh9s6egTfrHHohaZZWo0D+k3gMnXrXegLpA=; b=hFaU0Rrpg7jEBpRGFDIG3Ob9XwwuMiQoVijoYiRWxd8BlIwsZxjuWgX6OF5f0w9ewb aJvp2yrzPuwAZZjFdKc0MG3AasjzC0xyU+eUh2Xsf225CUorhYLvZi1P2n2IbnMDm4c3 Bya8eZTuKsO254dU8q+eM+w9XJrHzNYyyyXbg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; b=IA3UV2FgI7pe9tl/Ie5203HxkR0xLbfaL0ateZKhcaOq4MBvi+ZX+tlvX8GmXXFM7u JStHX/qz7oCJbf0+gF6yrLj7GEz9F9v07M7rJAwJ5tEwhfG7e6LRHL/TPV9QqR+xRtbM O24qxlJpnJArVI+TzkzeLkGy/jK0Leveav/NY= MIME-Version: 1.0 Received: by 10.100.57.1 with SMTP id f1mr149812ana.205.1283883175793; Tue, 07 Sep 2010 11:12:55 -0700 (PDT) Sender: mdf356@gmail.com Received: by 10.100.126.20 with HTTP; Tue, 7 Sep 2010 11:12:55 -0700 (PDT) Date: Tue, 7 Sep 2010 11:12:55 -0700 X-Google-Sender-Auth: EGoRbS9GjK4jwFwDqxOr0gw90Is Message-ID: From: mdf@FreeBSD.org To: FreeBSD Arch Content-Type: text/plain; charset=ISO-8859-1 Subject: 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: Tue, 07 Sep 2010 18:12:57 -0000 Isilon developed a formatted print system basically in parallel with FreeBSD's sbuf code. One of the things isi_format has that sbuf is lacking is the comcept of a drain. Basically a drain is a way to limit the size of the sbuf and, instead of reallocating the buffer when it is full, the contents are flushed under the control of a callback to "elsewhere". The common drains used at Isilon are to flush to log(9), printf(9), and SYSCTL_OUT(9). One of the advantages to using drains is that formatted print functions don't need to know where the data is going; they just always print to an sbuf and let the caller of the formatted print function know what he intended with the data. The first two patches simplify the sbuf(9) code a little. http://people.freebsd.org/~mdf/0001-Replace-the-SBUF_OVERFLOWED-flag-with-an-s_error-cod.patch http://people.freebsd.org/~mdf/0002-Compare-SBUF_FREESPACE-against-0-instead-of-using-th.patch This is the main patch, which uses the drain functionality to extend sbufs (unless the drain is overridden), and also creates an initializer for draining to a sysctl_req. The man page changes are included in this patch. http://people.freebsd.org/~mdf/0003-Add-drain-functionality-to-sbufs.-The-drain-is-a-fun.patch I would like to commit this work later this week. One possibility to allow MFC is to package the drain variables (function pointer, argument, error code storage) into an sbuf_drain struct and use the s_unused field to point to a caller-supplied storage for the drain data. I didn't go this way since it seemed more awkward long term. There is a need for regression suite against libsbuf. I looked at the existing tests for libutil to try to understand it but the syntax of expected results was beyond my comprehension at this time. Questions? Comments? Bug reports? As I indicate in a comment in sbuf.h, it seems that the buffered printf(2) functionality could be implemented using sbufs as the buffer and different drains depending on which kind of printf is wanted: one drain to a string buffer ala sprintf, one to a FILE* ala fprintf, etc. This seems cleaner than the existing FAKE_FILE hack to get fprintf(2) to print to a string. However, the printf(2) code was also rather obtuse and I haven't had time to untangle it yet. Thanks, matthew From owner-freebsd-arch@FreeBSD.ORG Tue Sep 7 19:19:41 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 2E2731065696 for ; Tue, 7 Sep 2010 19:19:41 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id AAA7C8FC1A for ; Tue, 7 Sep 2010 19:19:40 +0000 (UTC) Received: by bwz20 with SMTP id 20so5352282bwz.13 for ; Tue, 07 Sep 2010 12:19:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=VQSdAfqXWjrcwJwD2pKu/7PJ36Dv2+vnfExsfcZ7Jdw=; b=XNAas9Lr6rFB9cTppzqPsgTUi+wTUCkGoI1qhv/IY6MBWH5eVTE5BUD0kg8oYEe+SJ QVgiRWmYM6IjlCwYhJWCOCkb4iWnbJqlcVJetvgoCg9n6axsTF9GmcXeF5uKlfEkqPNR 10q4Mzh4wwm+DrcF8KtxaPk6D7F1LfeKUQx7k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=LtJaFzQL0PCDyRRjCS+ki1S4neVcUVGlpAJoyZCcZ0utvppPCSyUoGT5yL7+vMcQ+a jcyXM9N/gVZXh2Z4qZCkG2NYADRCAhAzR27iYntFcvLjbAQUVRydZZXf8z9fs06Ywi0O OKG2XLw3BTqwEU0t1Te9Y6qhVOZmX7S+xvNuE= Received: by 10.204.141.16 with SMTP id k16mr1166976bku.177.1283885656040; Tue, 07 Sep 2010 11:54:16 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id g12sm5556278bkb.2.2010.09.07.11.54.13 (version=SSLv3 cipher=RC4-MD5); Tue, 07 Sep 2010 11:54:14 -0700 (PDT) Sender: Alexander Motin Message-ID: <4C868A43.6080405@FreeBSD.org> Date: Tue, 07 Sep 2010 21:53:55 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.24 (X11/20100402) MIME-Version: 1.0 To: "Cherry G. Mathew" References: <4C0C1AE4.8050807@FreeBSD.org> <4C864FFD.6020409@zyx.in> In-Reply-To: <4C864FFD.6020409@zyx.in> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-arch@freebsd.org Subject: Re: [resend] Re: RFC: New event timers infrastructure 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: Tue, 07 Sep 2010 19:19:41 -0000 Hi. Cherry G. Mathew wrote: > On 6/6/2010 10:02 PM, Alexander Motin wrote: >> I did such things: >> - created unified timer driver's API (sys/timeet.h, kernel/kern_et.c). >> It supports global and per-CPU timers, periodic and one-shot. Provides >> driver and consumer interfaces for choosing timers and operating them; > > [...] > >> Latest patches can be found here: >> http://people.freebsd.org/~mav/et.20100606.patch > > Had you considered integrating this api with sys/timetc.h ? Most timer > devices which can interrupt after a certain period of time, can also > provide counters, I would imagine ? I don't see much reasons to do it. These systems are quite different. The almost only API intersection is device choosing algorithm and even in that case some device that is perfect as time counter can be the worst as event timer, so there indeed will be two lists independent ordered lists. Another intersection could be in using same tick periods for both time counter and event timers, but I think it will just mess code. At this moment event timers accept bintime as periods arguments and time counters also after adjustments are getting translated into bintime. It looks much more universal and transparent, especially when system uses different hardware for time counter and event timer. There is not so much hardware that can be used as both time counter and event timer. For example, on x86: - i8254 can do both, but preferably not at the same time and never both with event timer in one-shot mode; - RTC - only event timer; - LAPIC - only event timer; - HPET - both: one time counter and 3-8 event timers; - TSC - only time counter; - ACPI timer - only time counter. > I'd be keen to know your thoughts on providing the ability of et > consumers to daisy chain to a single eventtimer. I am not sure why it is needed. With my latest work on one-shot mode timers it is possible to use single timer for any number of events. At this moments for three: hardclock, statclock, proflock. They are separated for legacy reasons so I wasn't breaking it for now. Same time, if we need to have more consumers - we can either add them in the same way (bad way) or make some king of universal event scheduler for this -- like out callouts callwheel, but without tick period dependency. The last way in fact will give us really tick-less kernel. > It would be good for et_find() to query for timers that can guarantee a > specific resolution/period or below/above. I don't see problem to do it. I was just not needed. We may even allow every application to traverse that list to decide what it wants. But for present purposes I don't see enough reasons to do it. After reviewing many of our architectures I've fount that x86 probably have more timers then any other. Most of other platforms have only 1-2 timers (at least supported now or which I have found). So really complicated algorithm seems excessive there. > Finally, I'm curious to know what et_quality implies ? Perhaps it can be > an indication of the max/min resolution/period available from a given et ? There is many factors affecting "how good is this timer". Mostly it is not a question of precision. Usually it is question of functionality, performance, reliability and so on. At this moment I am manually assigning qualities in a way that allows kern_clocksource.c code to make more or less reasonable choice in most of situations. For example, RTC timer has very high granularity - prefer i8254 instead if possible; i8254 can't do one-shot mode due to being also an time counter - prefer LAPIC; if specific LAPIC timer dies in C3 state - it may be a good reason to prefer HPET. -- Alexander Motin From owner-freebsd-arch@FreeBSD.ORG Tue Sep 7 19:40:41 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 C9D3010656E2; Tue, 7 Sep 2010 19:40:41 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 8B01E8FC19; Tue, 7 Sep 2010 19:40:41 +0000 (UTC) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 2E0043F5C4; Tue, 7 Sep 2010 19:40:40 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.4/8.14.4) with ESMTP id o87JedSH049782; Tue, 7 Sep 2010 19:40:40 GMT (envelope-from phk@critter.freebsd.dk) To: mdf@FreeBSD.org From: "Poul-Henning Kamp" In-Reply-To: Your message of "Tue, 07 Sep 2010 11:12:55 MST." Date: Tue, 07 Sep 2010 19:40:39 +0000 Message-ID: <49781.1283888439@critter.freebsd.dk> Sender: phk@critter.freebsd.dk 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: Tue, 07 Sep 2010 19:40:42 -0000 In message , mdf@ FreeBSD.org writes: Not so fast... The first patch (0001...) I am basically OK with. I question the choice of EOVERFLOW, which is generally for fixed size data structures. I think that should be changed to ENOMEM, pretty much throughout. I'm not sure I see much point in the second patch (0002...) but whatever. The third patch (0003...) Is not ok with me, for a number of reasons. First, I am not even sure we should add this to sbuf in the first place. Both userland and kernel printf's have half-assed support for random drain functions already. On the other hand, those functions are PITA to use and mostly undocumented hacks, so we should get something better constructed. Sbufs were designed to provide overflow-safe string operations on buffers (static or dynamic) with latching error detection. They were not designed to become a generalized I/O stream facility. By adding drain functionality to sbufs, we get significant overlap with stdio's FILE, but not anywhere close to being able to replace those. Is such near-duplication a good idea ? (Ohh, and while we're at it: If we modify sbufs anyway, should we add wchar_t support ?) If we decide to add drain function support to sbufs, I have issues with the suggested patches: For one thing, sbuf is not a kernel facility, it is a general purpose string editing library which is also used outside FreeBSD. If we add the drain facility it should work in both userland and kernel. The drain function does not, and should not have to know that sbufs are involved, it should have a prototype of: int sbuf_drain(void *private, const char *ptr, int len) Return value: >= 0 # bytes drained -1 error, errno relevante -2 error, errno not relevant Note: The the private argument should be a void*, not an uintptr_t This means that the autoextend can not be implemented in terms of a drain, but that looked plain wrong to me any way. The next thing is when do we call the drain function. If we add drain callbacks, we should do it right and offer all three canonical options: For every char When buffer is full. On line boundaries (ie: one or more lines) sbuf_flush() is unecessary, sbuf_finish() should be used, because that is the only way you can be sure the error code is available for checking afterwards. sbuf_unfinished_data() is just plain wrong and shall not be added, ever. The internals of sbufs are strictly private and should stay private. Sbuf does not make any promises about how the string is stored internally until you sbuf_finish() the buffer. By changing the drain prototype as per above, sbuf_unfinished_data() is not needed. Poul-Henning -- 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. From owner-freebsd-arch@FreeBSD.ORG Wed Sep 8 06:18:25 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 36F8410656C9; Wed, 8 Sep 2010 06:18:25 +0000 (UTC) (envelope-from cherry@zyx.in) Received: from reagan.nswebhost.com (reagan.nswebhost.com [64.22.87.10]) by mx1.freebsd.org (Postfix) with ESMTP id 7ABDF8FC13; Wed, 8 Sep 2010 06:18:24 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=zyx.in; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-Antivirus:X-Antivirus-Status; b=IIGn0TfT+ZRay/k107whZWFDNr7vGyM4AwIFQqpBaQpm3aqS640Sososxkjt5HMCOMv1O2KKeKwOcklPdMb15qNQagKhf4lC4+vjo0RPH4hrWM1DZsFzbJcpW9thac7u; Received: from [117.241.57.155] (port=64486 helo=[127.0.0.1]) by reagan.nswebhost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1OtDz9-0002Ye-Uq; Wed, 08 Sep 2010 01:18:21 -0500 Message-ID: <4C872AA4.5020906@zyx.in> Date: Wed, 08 Sep 2010 11:48:12 +0530 From: "Cherry G. Mathew" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.8) Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Alexander Motin References: <4C0C1AE4.8050807@FreeBSD.org> <4C864FFD.6020409@zyx.in> <4C868A43.6080405@FreeBSD.org> In-Reply-To: <4C868A43.6080405@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 100907-1, 09/07/2010), Outbound message X-Antivirus-Status: Clean X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - reagan.nswebhost.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - zyx.in Cc: freebsd-arch@freebsd.org Subject: Re: [resend] Re: RFC: New event timers infrastructure 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 06:18:25 -0000 On 9/8/2010 12:23 AM, Alexander Motin wrote: > Hi. > > Cherry G. Mathew wrote: >> On 6/6/2010 10:02 PM, Alexander Motin wrote: >>> I did such things: >>> - created unified timer driver's API (sys/timeet.h, kernel/kern_et.c). >>> It supports global and per-CPU timers, periodic and one-shot. Provides >>> driver and consumer interfaces for choosing timers and operating them; >> >> [...] >> >>> Latest patches can be found here: >>> http://people.freebsd.org/~mav/et.20100606.patch >> >> Had you considered integrating this api with sys/timetc.h ? Most timer >> devices which can interrupt after a certain period of time, can also >> provide counters, I would imagine ? > > I don't see much reasons to do it. These systems are quite different. > The almost only API intersection is device choosing algorithm and even > in that case some device that is perfect as time counter can be the > worst as event timer, I am not so sure this is as bad as it sounds. For eg: wouldn't a specific driver backend, like, say the attimer need to protect against concurrent port writes via both APIs, eg: from a oneshot event expiry callback and an asynchronous counter read callback (from the separate APIs) ? And surely, there is some correlation between timer counter resolution and event callback period "quality" for a given device ? I do see the cleanliness of abstraction you're arguing for, but I'm just saying this is perhaps a bit over-engineered ? > so there indeed will be two lists independent > ordered lists. > Or alternatively, daisy-chained callbacks ? You could have clients daisy-chaining callbacks on top of specific timecounters they care about ? btw, are there any RT constraints that the current event timer callbacks need to be worried about ? > Another intersection could be in using same tick periods for both time > counter and event timers, but I think it will just mess code. At this > moment event timers accept bintime as periods arguments and time > counters also after adjustments are getting translated into bintime. It > looks much more universal and transparent, especially when system uses > different hardware for time counter and event timer. > I agree that the abstractions are "clean"er. However, this isn't quite userland, is it ? I'm thinking of the case in which a specific hardware topology requires a driver to talk to a specific timer device, say, on an add-on board of some sort. > There is not so much hardware that can be used as both time counter and > event timer. For example, on x86: > - i8254 can do both, but preferably not at the same time and never both > with event timer in one-shot mode; > - RTC - only event timer; > - LAPIC - only event timer; An ideal opportunity to implement: { mtx_lock_spin(&clock_lock); softcounter++; mtx_unlock_spin(&clock_lock); } :-) > - HPET - both: one time counter and 3-8 event timers; > - TSC - only time counter; > - ACPI timer - only time counter. > >> I'd be keen to know your thoughts on providing the ability of et >> consumers to daisy chain to a single eventtimer. > > I am not sure why it is needed. With my latest work on one-shot mode > timers it is possible to use single timer for any number of events. At > this moments for three: hardclock, statclock, proflock. They are > separated for legacy reasons so I wasn't breaking it for now. Same time, This is in yet unpublished work, right ? 'cause I see: +int +et_init(struct eventtimer *et, et_event_cb_t *event, + et_deregister_cb_t *deregister, void *arg) +{ + + if (event == NULL) + return (EINVAL); + if (et->et_active) + return (EBUSY); ... > if we need to have more consumers - we can either add them in the same > way (bad way) or make some king of universal event scheduler for this -- > like out callouts callwheel, but without tick period dependency. The > last way in fact will give us really tick-less kernel. > I think the key thing I'm worried about here is consumer order. Is there a way in which this can be queried/set by consumers ? I imagine a generic scheduler would abstract this decision away from consumers as a "scheduling policy". >> It would be good for et_find() to query for timers that can guarantee a >> specific resolution/period or below/above. > > I don't see problem to do it. I was just not needed. We may even allow > every application to traverse that list to decide what it wants. But for > present purposes I don't see enough reasons to do it. After reviewing > many of our architectures I've fount that x86 probably have more timers > then any other. Most of other platforms have only 1-2 timers (at least > supported now or which I have found). So really complicated algorithm > seems excessive there. > Okay. I was thinking in the context of a wider consumer audience. >> Finally, I'm curious to know what et_quality implies ? Perhaps it can be >> an indication of the max/min resolution/period available from a given et ? > > There is many factors affecting "how good is this timer". Mostly it is > not a question of precision. Usually it is question of functionality, > performance, reliability and so on. At this moment I am manually > assigning qualities in a way that allows kern_clocksource.c code to make > more or less reasonable choice in most of situations. For example, RTC > timer has very high granularity - prefer i8254 instead if possible; > i8254 can't do one-shot mode due to being also an time counter - prefer > LAPIC; if specific LAPIC timer dies in C3 state - it may be a good > reason to prefer HPET. > Many thanks for the detailed explanation. -- cherry From owner-freebsd-arch@FreeBSD.ORG Wed Sep 8 07:19:12 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 29E3510656D6 for ; Wed, 8 Sep 2010 07:19:12 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id A01798FC0A for ; Wed, 8 Sep 2010 07:19:11 +0000 (UTC) Received: by bwz20 with SMTP id 20so5879846bwz.13 for ; Wed, 08 Sep 2010 00:19:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=MnuixKB7ahbwbxK/sC22pHXcLkPlmCmVI/SgVHYSeo4=; b=mHaRWuB8zoexIi18BD24F160eqx+sRbdNVch3EVB+A6dIuoKSyzLpSXYUWNJo7zHYi t8qOxgeGgOi9Yi1OXMnxvVPvVYe2n8P2KydR70Rx2Gkaufvq0p0rLdU8P2zmzlYJKMtd 1oyc8RkgVqFIXDIaW0ftL8FHLSJ3HozyxOkfQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=wPmysS8E9VbpDA6A1Qj3RuZkAhSoLzdy4CvLuMN56BgpHiEfe4HLnslSx1qSIvebtJ W+4dDZdm3tO+mJPDwj4LYJEX8DRX0wBVZk+ewVMnZzlFHUL01wSlDxLh1wIA/dYckTBF OlGFVQ1VK842G+P9cwOwwpPTlXmp4BbnDPvuY= Received: by 10.204.153.10 with SMTP id i10mr2034794bkw.1.1283930350492; Wed, 08 Sep 2010 00:19:10 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id 24sm6031221bkr.19.2010.09.08.00.19.08 (version=SSLv3 cipher=RC4-MD5); Wed, 08 Sep 2010 00:19:09 -0700 (PDT) Sender: Alexander Motin Message-ID: <4C8738DA.80604@FreeBSD.org> Date: Wed, 08 Sep 2010 10:18:50 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.24 (X11/20100402) MIME-Version: 1.0 To: "Cherry G. Mathew" References: <4C0C1AE4.8050807@FreeBSD.org> <4C864FFD.6020409@zyx.in> <4C868A43.6080405@FreeBSD.org> <4C872AA4.5020906@zyx.in> In-Reply-To: <4C872AA4.5020906@zyx.in> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-arch@freebsd.org Subject: Re: [resend] Re: RFC: New event timers infrastructure 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 07:19:12 -0000 Cherry G. Mathew wrote: > On 9/8/2010 12:23 AM, Alexander Motin wrote: >> Cherry G. Mathew wrote: >>> On 6/6/2010 10:02 PM, Alexander Motin wrote: >>>> I did such things: >>>> - created unified timer driver's API (sys/timeet.h, >>>> kernel/kern_et.c). >>>> It supports global and per-CPU timers, periodic and one-shot. Provides >>>> driver and consumer interfaces for choosing timers and operating them; >>> >>> [...] >>> >>>> Latest patches can be found here: >>>> http://people.freebsd.org/~mav/et.20100606.patch >>> >>> Had you considered integrating this api with sys/timetc.h ? Most timer >>> devices which can interrupt after a certain period of time, can also >>> provide counters, I would imagine ? >> >> I don't see much reasons to do it. These systems are quite different. >> The almost only API intersection is device choosing algorithm and even >> in that case some device that is perfect as time counter can be the >> worst as event timer, > > I am not so sure this is as bad as it sounds. For eg: wouldn't a > specific driver backend, like, say the attimer need to protect against > concurrent port writes via both APIs, eg: from a oneshot event expiry > callback and an asynchronous counter read callback (from the separate > APIs) ? And surely, there is some correlation between timer counter > resolution and event callback period "quality" for a given device ? I do > see the cleanliness of abstraction you're arguing for, but I'm just > saying this is perhaps a bit over-engineered ? For the most of hardware I've seen, reading doesn't need any locking. Mostly it may be needed if we will try emulate time counter using hardware that intended to be and used and event timer (like i8254). But IMHO that it dead end, and whenever it is possible, I would prefer not to do it. And even so, why locking can't be done just inside the driver if it is it's own business? At this moment I am not defining any timer locking at event timer API (kern_et.c). API only protects timer list access. Timers themselves now protected by separate lock in consumer which grabbed them (kern_clocksource.c). >> so there indeed will be two lists independent >> ordered lists. > > Or alternatively, daisy-chained callbacks ? You could have clients > daisy-chaining callbacks on top of specific timecounters they care about ? What do you mean by daisy-chaining? For example, if we have timer supporting only periodic mode and two consumers, requiring frequencies of 100Hz and 127Hz precisely. How do you wish them to chain? What frequency write into the timer? 12700Hz? If you have no other timers to live separately - obviously you have to implement some kind of scheduling. But I believe it is the next level of abstraction, outside of present API. > btw, are there any RT constraints that the current event timer callbacks > need to be worried about ? You mean interrupt latency constraints? Except reasonable callouts time precision I don't remember other constraints. >> Another intersection could be in using same tick periods for both time >> counter and event timers, but I think it will just mess code. At this >> moment event timers accept bintime as periods arguments and time >> counters also after adjustments are getting translated into bintime. It >> looks much more universal and transparent, especially when system uses >> different hardware for time counter and event timer. > > I agree that the abstractions are "clean"er. However, this isn't quite > userland, is it ? I'm thinking of the case in which a specific hardware > topology requires a driver to talk to a specific timer device, say, on > an add-on board of some sort. Not sure what do you mean by "quite userland". This is low-level event timer hardware abstraction. It is not exposed to user-level and I am not sure about cases when it should be used even in kernel instead of using standard callout mechanism or it's possible further tickless successors. If you wish to work with specific event timer - you can ask et_find() to give one to you, specifying it's name, and if it is not yet busy - use if freely for whatever you want. >> There is not so much hardware that can be used as both time counter and >> event timer. For example, on x86: >> - i8254 can do both, but preferably not at the same time and never both >> with event timer in one-shot mode; >> - RTC - only event timer; >> - LAPIC - only event timer; > > An ideal opportunity to implement: > > { > mtx_lock_spin(&clock_lock); > softcounter++; > mtx_unlock_spin(&clock_lock); > } :) It will give you terrible precision or huge interrupt rate. >> - HPET - both: one time counter and 3-8 event timers; >> - TSC - only time counter; >> - ACPI timer - only time counter. >> >>> I'd be keen to know your thoughts on providing the ability of et >>> consumers to daisy chain to a single eventtimer. >> >> I am not sure why it is needed. With my latest work on one-shot mode >> timers it is possible to use single timer for any number of events. At >> this moments for three: hardclock, statclock, proflock. They are >> separated for legacy reasons so I wasn't breaking it for now. Same time, > > This is in yet unpublished work, right ? 'cause I see: I was talking about this: http://docs.freebsd.org/cgi/mid.cgi?4C7A5C28.1090904 Trivial scheduling for hardclock, statclock and proflock from single one-shot hardware event timer implemented at kern_clocksource.c. >> if we need to have more consumers - we can either add them in the same >> way (bad way) or make some king of universal event scheduler for this -- >> like out callouts callwheel, but without tick period dependency. The >> last way in fact will give us really tick-less kernel. > > I think the key thing I'm worried about here is consumer order. Is there > a way in which this can be queried/set by consumers ? I imagine a > generic scheduler would abstract this decision away from consumers as a > "scheduling policy". Are you talking about callback order in case of two simultaneous events? because if events are not scheduled as simultaneous (up to 64-bit precision) they could be called respectively to that order. Question is about interrupt latency or what? -- Alexander Motin From owner-freebsd-arch@FreeBSD.ORG Wed Sep 8 15:43:42 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 E560710656F4 for ; Wed, 8 Sep 2010 15:43:41 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 9B3F68FC21 for ; Wed, 8 Sep 2010 15:43:41 +0000 (UTC) Received: by gwb15 with SMTP id 15so107791gwb.13 for ; Wed, 08 Sep 2010 08:43:40 -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=S9/ludeN/WUQlUYuMKPXs5Vk3cI89LeXWfhFmQrUupg=; b=erZ4k1wS8d2nA5SktIXtCCcoLlQvoLe+c0p/oXqmuWMar1e94a4WAW93RzHikpr/1t 1JA5E5t3AYXYU1z/ItukdFqWyc6HAn6r9PPdUH5SKMMsfNzLfGtZN8+Xaya0SRKaYgXK PTQn83iCCZswC5i5RwHs08qoe6F6J243wHrUk= 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=JmHPi2WFD75nhRD/8Zjc5jhi7yvor9ceRVHE+KHOszWaWDfXqqU3lMPMfne0lZgP61 8m93w59jq4YTqMIyilBRP6nmpL5ljVIL7gQ9yfeBo6jsl9Z/D+dqLzaNgXcvcaA9xig9 qvgvGaW6fEtqq4dAX74a2+lBtDQXrZczMl7v8= MIME-Version: 1.0 Received: by 10.100.151.11 with SMTP id y11mr148617and.4.1283960620541; Wed, 08 Sep 2010 08:43:40 -0700 (PDT) Sender: mdf356@gmail.com Received: by 10.100.126.20 with HTTP; Wed, 8 Sep 2010 08:43:40 -0700 (PDT) In-Reply-To: <49781.1283888439@critter.freebsd.dk> References: <49781.1283888439@critter.freebsd.dk> Date: Wed, 8 Sep 2010 08:43:40 -0700 X-Google-Sender-Auth: JOvhyP5mRF3qaB8R3dYRA5IzIY8 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 15:43:42 -0000 On Tue, Sep 7, 2010 at 12:40 PM, Poul-Henning Kamp wro= te: > In message , mdf@ > FreeBSD.org writes: > > Not so fast... > > The first patch (0001...) I am basically OK with. =A0I question the > choice of EOVERFLOW, which is generally for fixed size data structures. > I think that should be changed to ENOMEM, pretty much throughout. > > I'm not sure I see much point in the second patch (0002...) but > whatever. > > The third patch (0003...) Is not ok with me, for a number of reasons. > > First, I am not even sure we should add this to sbuf in the first > place. > > Both userland and kernel printf's have half-assed support for random > drain functions already. =A0On the other hand, those functions are > PITA to use and mostly undocumented hacks, so we should get something > better constructed. This was an attempt to construct something better. It may not be in a final form, but these drains seem pretty useful to me. What is the half-assed support you mention? Is that the func callback for kvprintf(9) and the general nature of a FILE object for printf(3) ? > Sbufs were designed to provide overflow-safe string operations on > buffers (static or dynamic) with latching error detection. > They were not designed to become a generalized I/O stream facility. > > By adding drain functionality to sbufs, we get significant overlap > with stdio's FILE, but not anywhere close to being able to replace > those. To me, since FILE is a C standard object, it is what it is. These sbuf drains can be used to implement FILE buffering if desired, and apart from my difficulty understanding the user-space implementation of printf(3), that was my intent. Regardless of what sbufs were originally designed to do, this seems like a useful enhancement to me that does not take away the ability to use them for overflow detection. An sbuf without a drain marked SBUF_FIXED will still perform in this manner. But now there are more options. > If we decide to add drain function support to sbufs, I have issues > with the suggested patches: > > For one thing, sbuf is not a kernel facility, it is a general purpose > string editing library which is also used outside FreeBSD. =A0 If > we add the drain facility it should work in both userland and kernel. Given that sys/sbuf.h is included in 100+ kernel files and 4 user-space files, and the man page is in section 9, and the support was originally kernel-only and only later was libsbuf added, I think of sbuf(9) as a kernel facility that happens to be useable in user-space as well. The patch I provided doesn't have drains for user-space simply because the existing printf(3) implementation did not seem like it was workable as-is, and would require some modifications to work as intended. I don't have the time now to look into that, and I'm completely unfamiliar with any details of the user-space printf(3) implementation except what I learned in an hour of looking over the code. As for being used outside FreeBSD, I was unaware of this. Who is using it, and what kinds of code are we pulling from the other implementations? > The drain function does not, and should not have to know that sbufs > are involved Why not? This is an assertion without any proof. Allowing the drain to receive the sbuf pointer as an argument allows for future flexibility I haven't even imagined yet. > it should have a prototype of: > > =A0 =A0 =A0 =A0int sbuf_drain(void *private, const char *ptr, int len) > > Return value: > =A0 =A0 =A0 =A0>=3D 0 =A0 =A0# bytes drained > =A0 =A0 =A0 =A0-1 =A0 =A0 =A0error, errno relevante > =A0 =A0 =A0 =A0-2 =A0 =A0 =A0error, errno not relevant This prototype and return scheme does not work in the kernel where there is no errno. Note that in the existing implementation, sbuf_extend() will return -1 and not set errno in the case where SBUF_AUTOEXTEND is not set. sbuf_setpos() will return -1 but not ser errno to ERANGE when the position argument is out of range. Similarly for most of the -1 return codes for sbuf; errno is never explicitly set in the code and only rarely implicitly set, e.g. by a failed malloc(3). We could go a Linux route and a positive value means the number of bytes drained and negative is the -errno, but that does not seem to be a FreeBSD style. Given this, I chose instead to have an sbuf_drained() function so the drain can explicitly indicate if it has drained any bytes. > Note: The the private argument should be a void*, not an uintptr_t I seem to recall that casting a pointer to uintptr_t and back is safe according to the C standard, but casting an integral value to a void * and back is not. Thus my choice of uintptr_t. If this is incorrect, then it doesn't matter and I'm just as happy to use a void *. > This means that the autoextend can not be implemented in terms of > a drain, but that looked plain wrong to me any way. Implementing autoextend as a drain shows off the flexibility of the drain function, among other things. It also simplifies the sbuf code in that it doesn't need to add special cases for s_drain_func =3D=3D NULL and call sbuf_extend in those cases. > The next thing is when do we call the drain function. =A0If we add > drain callbacks, we should do it right and offer all three canonical > options: > > =A0 =A0 =A0 =A0For every char > =A0 =A0 =A0 =A0When buffer is full. > =A0 =A0 =A0 =A0On line boundaries (ie: one or more lines) Two of these three are available in my patch. To be called for every char, initialize with a buffer of length 2. Adding a call on line boundaries is a simple patch that can be added when desired. That functionality can be simulated by having the drain function check for the '\n' and only draining that much. Line boundaries will never be perfect since a line can always exceed whatever static sized buffer is used. > sbuf_flush() is unecessary, sbuf_finish() should be used, because > that is the only way you can be sure the error code is available > for checking afterwards. With the existing sbuf_finish() implementation, it was unusable. Mostly because of the SBUF_FINISHED state change. There is no reason off-hand that I can think of to have the sbuf track whether it's really "done"; that is up to the user of the service who should know whether all the data has been printed to the sbuf. More below... > sbuf_unfinished_data() is just plain wrong and shall not be added, ever. This was required because of the assert_sbuf_state(SBUF_FINISHED) assert in sbuf_data. If sbuf_data() always NUL-terminated and didn't assert on the sbuf state, then sbuf_unfinished_data() would be unneeded and I'd prefer this. > The internals of sbufs are strictly private and should stay private. > > Sbuf does not make any promises about how the string is stored > internally until you sbuf_finish() the buffer. sbuf did make this promise. Since sbuf_data and sbuf_len are public accessor functions, it seems reasonable to use them in the drain callback. I'm not entirely opposed to passing in a char *buf and int len as well to the drain, but it seemed redundant given the existence of sbuf_len() and sbuf_data(). The current implementation makes no guarantees about how the string is stored until sbuf_finish(), but this can be changed so that sbuf_data does guarantee exactly what the prototype offers: a pointer to a NUL-terminated, contiguous sequence of bytes that represents the contents of the sbuf, and the invariant can become that the state of the data isn't guaranteed until a call to sbuf_data(). So to summarize: you have made some objections but in general I don't feel that you have provided sufficient reasoning behind those objections. So I would like to continue this conversation and work out something that is acceptable to both of us (and the silent gallery). Thanks, matthew From owner-freebsd-arch@FreeBSD.ORG Wed Sep 8 16:29:59 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 087C8106564A; Wed, 8 Sep 2010 16:29:59 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 7CE1D8FC1A; Wed, 8 Sep 2010 16:29:58 +0000 (UTC) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id F19393F60E; Wed, 8 Sep 2010 16:29:56 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.4/8.14.4) with ESMTP id o88GTu6b067050; Wed, 8 Sep 2010 16:29:56 GMT (envelope-from phk@critter.freebsd.dk) To: mdf@FreeBSD.org From: "Poul-Henning Kamp" In-Reply-To: Your message of "Wed, 08 Sep 2010 08:43:40 MST." Date: Wed, 08 Sep 2010 16:29:56 +0000 Message-ID: <67049.1283963396@critter.freebsd.dk> Sender: phk@critter.freebsd.dk 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 16:29:59 -0000 In message , mdf@ FreeBSD.org writes: >Regardless of what sbufs were originally designed to do, this seems >like a useful enhancement to me that does not take away the ability to >use them for overflow detection. An sbuf without a drain marked >SBUF_FIXED will still perform in this manner. But now there are more >options. I am not saying it is not useful, I am questioning if sbufs is the right vehicle for this usefulness. >> For one thing, sbuf is not a kernel facility, it is a general purpose >> string editing library which is also used outside FreeBSD. If >> we add the drain facility it should work in both userland and kernel. > >Given that sys/sbuf.h is included in 100+ kernel files and 4 >user-space files, [...] That is probably more an indication that our userland is largely unchanged from 1995, whereas as everybody loves to hack up the kernel :-) The various people who have told me they adopted sbufs have been very happy with them in userland. >As for being used outside FreeBSD, I was unaware of this. Who is >using it, and what kinds of code are we pulling from the other >implementations? As usual with the BSD license, we have no idea and no way to find out. One place I do know about is Varnish :-) My main point here is that you should not treat sbufs as a kernel facility, but see it as a generally desirable and useful way of doing safe string operations, and that if we make a major extension in functionality, it should be done both in userland and kernel. >> The drain function does not, and should not have to know that sbufs >> are involved > >Why not? This is an assertion without any proof. See later in my previous reply: The contents of sbufs is private, nobody outside subr_sbuf.c should ever fondle the internals. See further below. >to receive the sbuf pointer as an argument allows for future >flexibility I haven't even imagined yet. I'll let Gettys (The programmer, not the general) shoot that canard down: 3. The only thing worse than generalizing from one example is generalizing from no examples at all. >> int sbuf_drain(void *private, const char *ptr, int len) >> >> Return value: >> >= 0 # bytes drained >> -1 error, errno relevante >> -2 error, errno not relevant > >This prototype and return scheme does not work in the kernel where >there is no errno. Which bit of "errno not relevant" in the description of -2 did you fail to notice ? :-) >Note that in the existing implementation, >sbuf_extend() will return -1 and not set errno in the case where >SBUF_AUTOEXTEND is not set. You were the one to involve errno's in this (patch 0001...) I don't see them having any relevance, since ENOMEM is the only one that's realistically relevant. Realistiscally you could have a drain function that dumps into a socket (userland or kernel) and it would be nice to report the ECONNRESET back. I was never really happy with des@' choice of the name sbuf_overflowed() I would have prefered sbuf_error() or sbuf_ok(). If we decide to introduce errnos, this gives us the chance to add those and advocate their use instead of sbuf_overflowed(). >> Note: The the private argument should be a void*, not an uintptr_t > >I seem to recall that casting a pointer to uintptr_t and back is safe Yes, but why would you want to ? Normally private arguments are typed "void *" as they more often than not point to some structure, to which you can cast a void* directly, whereas uintptr_t requires a explicit cast. >> This means that the autoextend can not be implemented in terms of >> a drain, but that looked plain wrong to me any way. > >Implementing autoextend as a drain shows off the flexibility of the >drain function, among other things. Uhm no, it does not. It results in the wrong prototype for the drain function, exposes the sbuf internals where they should not be fondled, and requires the addition of two extra functions which are unnecessary with the simpler prototype I suggested above. >Line boundaries will never be >perfect since a line can always exceed whatever static sized buffer is >used. Good point, forget about drain-policy then. The size 2 buffer for char by char requires good documentation and possibly a distinct #define. >> sbuf_flush() is unecessary, sbuf_finish() should be used, because >> that is the only way you can be sure the error code is available >> for checking afterwards. > >With the existing sbuf_finish() implementation, it was unusable. >Mostly because of the SBUF_FINISHED state change. There is no reason >off-hand that I can think of to have the sbuf track whether it's >really "done"; that is up to the user of the service who should know >whether all the data has been printed to the sbuf. More below... The critical feature of the sbuf API is that you do not need to check the error status on every call. That is why UNIX grew the EPIPE hack: nobody checks the return value of printf(). With sbufs no damage happens, no matter what you do, and you can (and should!) check the compound operation at the end with sbuf_overflowed(). For a sbuf with a drain function, sbuf_finish() should flush the buffer, but it should probably not set the SBUF_FINISHED flag. That would also catch confused calls to sbuf_data() with an assert. What is the semantics of sbuf_len() when you have a drain function ? Number of undrained bytes ? >> sbuf_unfinished_data() is just plain wrong and shall not be added, ever. > >This was required because of the assert_sbuf_state(SBUF_FINISHED) No, this was required because you chose the wrong prototype for the drain function. >> The internals of sbufs are strictly private and should stay private. >> >> Sbuf does not make any promises about how the string is stored >> internally until you sbuf_finish() the buffer. > >sbuf did make this promise. Since sbuf_data and sbuf_len are public >accessor functions [...] Sbuf made no such promise, sbuf_data() and sbuf_len() are there precisly to isolate the internals. Amongst the original ideas was to have a multipart buffer to avoid multiple realloc()/memcpy operations on buffer extends, and only collapse the buffer at the end when the final size was known. This optimization has so far not been necessary. Your API change would make it impossible. Poul-Henning -- 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. From owner-freebsd-arch@FreeBSD.ORG Wed Sep 8 17:10:08 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 7404110656CE for ; Wed, 8 Sep 2010 17:10:08 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 219C88FC21 for ; Wed, 8 Sep 2010 17:10:07 +0000 (UTC) Received: by gyg4 with SMTP id 4so180775gyg.13 for ; Wed, 08 Sep 2010 10:10:07 -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=0/AxsA3EIuxrhw7hrqZnhI6w0OAL1mxgbNFRGmVV/zE=; b=lhCOXR+bdLTzj9MtHXiQp9H4Eq7+miIJRSPzbo5XICnTZsVWCRI0qqWy7n1O3h2DHF 3Cs2GG44oL4UpRG60vmTBMw/0+M5rO1cYcsXWB/hbpOvdHgIZj5fp8Nkjv+HWKx2MpIa 4qFF9qjrvWHYH9Lr54ZT5xZn2GYQcwvTfTAOM= 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=CUfqp2cO1mFbd2SUj4AEwTYKHQOiidvYlzD+RrZTrn9qMwvFveh5jyO9TdsoGx+wfD crPCjI7zfRmwRhOo8va+kMEDwbDcYGwItaBdQDc8OABJKiE3kcZ/uyQs+FM3Ryp6dPee qrBcvOADo14cOPpYobqV5+2r9wkUgZs8Tvs5E= MIME-Version: 1.0 Received: by 10.100.33.3 with SMTP id g3mr233363ang.170.1283965807060; Wed, 08 Sep 2010 10:10:07 -0700 (PDT) Sender: mdf356@gmail.com Received: by 10.100.126.20 with HTTP; Wed, 8 Sep 2010 10:10:06 -0700 (PDT) In-Reply-To: <67049.1283963396@critter.freebsd.dk> References: <67049.1283963396@critter.freebsd.dk> Date: Wed, 8 Sep 2010 10:10:06 -0700 X-Google-Sender-Auth: J-htFkasXHopFvLDE0gBsJbKjJk 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:10:08 -0000 On Wed, Sep 8, 2010 at 9:29 AM, Poul-Henning Kamp wrot= e: > In message = , mdf@ > FreeBSD.org writes: > >>Regardless of what sbufs were originally designed to do, this seems >>like a useful enhancement to me that does not take away the ability to >>use them for overflow detection. =A0An sbuf without a drain marked >>SBUF_FIXED will still perform in this manner. =A0But now there are more >>options. > > I am not saying it is not useful, I am questioning if sbufs is the > right vehicle for this usefulness. I chose to put it in sbuf because it's essentially impossible to put it in a structure that uses sbuf for its implementation. In order to know that draining is possible, one needs to know before the buffer has overflowed. If you think sbuf isn't the right vehicle (and I can understand that argument) can you please suggest something else? In the end I would like a One True Printf to bind them all, and printf(), sprintf(), fprintf(), log(), console(), etc., are all implemented using the One True Printf. Allowing the attach of a generic drain function aids this goal, because the functions that print data structure internals or whatever only need to know to print to an sbuf (or a struct format, if you prefer), and the user who initialized the struct knows where she intended to print. The unbuffered kernel kvprintf(9) makes implementing this easy. As I said, I haven't figured out how to implement this with printf(3) but I can at least see how to implement buffered print in userspace with sbuf at the core. >>> For one thing, sbuf is not a kernel facility, it is a general purpose >>> string editing library which is also used outside FreeBSD. =A0 If >>> we add the drain facility it should work in both userland and kernel. >> >>Given that sys/sbuf.h is included in 100+ kernel files and 4 >>user-space files, [...] > > That is probably more an indication that our userland is largely > unchanged from 1995, whereas as everybody loves to hack up the > kernel :-) =A0The various people who have told me they adopted sbufs > have been very happy with them in userland. > >>As for being used outside FreeBSD, I was unaware of this. =A0Who is >>using it, and what kinds of code are we pulling from the other >>implementations? > > As usual with the BSD license, we have no idea and no way to find out. > > One place I do know about is Varnish :-) > > My main point here is that you should not treat sbufs as a kernel > facility, but see it as a generally desirable and useful way of > doing safe string operations, and that if we make a major extension > in functionality, it should be done both in userland and kernel. I don't object to adding drains to userland. I want to. I merely stated that, at the moment, given the implementation of sprintf(3) through __vfprintf() and FAKE_FILE, it is not possible. That implementation would need to be changed and it is beyond the scope of my current knowledge and time. My current patch doesn't have it, but that doesn't mean the patch is wrong. I would assume that, if someone really wants this is userland before I can get to this (and it is on my list of desired things to do) then they can write the code first. >>> The drain function does not, and should not have to know that sbufs >>> are involved >> >>Why not? =A0This is an assertion without any proof. > > See later in my previous reply: =A0The contents of sbufs is private, > nobody outside subr_sbuf.c should ever fondle the internals. =A0See > further below. > >>to receive the sbuf pointer as an argument allows for future >>flexibility I haven't even imagined yet. > > I'll let Gettys (The programmer, not the general) shoot that canard down: > > =A0 3. The only thing worse than generalizing from one example > =A0 =A0 =A0is generalizing from no examples at all. > >>> int sbuf_drain(void *private, const char *ptr, int len) >>> >>> Return value: >>> =A0>=3D 0 =A0# bytes drained >>> =A0 =A0 =A0 =A0-1 =A0 =A0 =A0error, errno relevante >>> =A0 =A0 =A0 =A0-2 =A0 =A0 =A0error, errno not relevant >> >>This prototype and return scheme does not work in the kernel where >>there is no errno. > > Which bit of "errno not relevant" in the description of -2 did > you fail to notice ? =A0:-) Well, the specific error code is relevant, and I don't really want an sbuf_set_error() function. For example, if my drain function is SYSCTL_OUT, I want to preserve the error code that returned. If my drain function is write(2) in userland, I want to preserve errno. The error code is very useful, and throwing it away for the kernel is wrong. >>Note that in the existing implementation, >>sbuf_extend() will return -1 and not set errno in the case where >>SBUF_AUTOEXTEND is not set. > > You were the one to involve errno's in this (patch 0001...) I > don't see them having any relevance, since ENOMEM is the only > one that's realistically relevant. Not with a generic drain function. sbuf_finish() / sbuf_flush() should be returning the error code, or at least providing a way to fetch it. > Realistiscally you could have a drain function that dumps into > a socket (userland or kernel) and it would be nice to report > the ECONNRESET back. > > I was never really happy with des@' choice of the name sbuf_overflowed() > I would have prefered sbuf_error() or sbuf_ok(). =A0 If we decide to > introduce errnos, this gives us the chance to add those and advocate > their use instead of sbuf_overflowed(). > >>> Note: The the private argument should be a void*, not an uintptr_t >> >>I seem to recall that casting a pointer to uintptr_t and back is safe > > Yes, but why would you want to ? =A0Normally private arguments are typed > "void *" as they more often than not point to some structure, to > which you can cast a void* directly, whereas uintptr_t requires a > explicit cast. If my drain function is in userspace and writes to a file descriptor I'd want it. >>> This means that the autoextend can not be implemented in terms of >>> a drain, but that looked plain wrong to me any way. >> >>Implementing autoextend as a drain shows off the flexibility of the >>drain function, among other things. > > Uhm no, it does not. > > It results in the wrong prototype for the drain function, exposes > the sbuf internals where they should not be fondled, and requires > the addition of two extra functions which are unnecessary with the > simpler prototype I suggested above. Autoextend did not dictate the drain prototype. The autoextend drain *is* an sbuf internal function -- note its existence in subr_sbuf.c. There may be other desired uses for a drain that don't just print to a file/console/log, though those are the most likely. >>Line boundaries will never be >>perfect since a line can always exceed whatever static sized buffer is >>used. > > Good point, forget about drain-policy then. > > The size 2 buffer for char by char requires good documentation and > possibly a distinct #define. > >>> sbuf_flush() is unecessary, sbuf_finish() should be used, because >>> that is the only way you can be sure the error code is available >>> for checking afterwards. >> >>With the existing sbuf_finish() implementation, it was unusable. >>Mostly because of the SBUF_FINISHED state change. =A0There is no reason >>off-hand that I can think of to have the sbuf track whether it's >>really "done"; that is up to the user of the service who should know >>whether all the data has been printed to the sbuf. =A0More below... > > The critical feature of the sbuf API is that you do not need to > check the error status on every call. =A0That is why UNIX grew the > EPIPE hack: nobody checks the return value of printf(). > > With sbufs no damage happens, no matter what you do, and you can > (and should!) check the compound operation at the end with > sbuf_overflowed(). > > For a sbuf with a drain function, sbuf_finish() should flush the > buffer, but it should probably not set the SBUF_FINISHED flag. =A0That > would also catch confused calls to sbuf_data() with an assert. > > What is the semantics of sbuf_len() when you have a drain function ? > > Number of undrained bytes ? Yes. If you attach an explicit drain function, the expected use is that you also don't care about the len, because you are flushing to a file/pipe/console/log and the only thing to be done after all the printing is to call sbuf_finish() or sbuf_flush() as I named it. >>> sbuf_unfinished_data() is just plain wrong and shall not be added, ever= . >> >>This was required because of the assert_sbuf_state(SBUF_FINISHED) > > No, this was required because you chose the wrong prototype for the > drain function. > >>> The internals of sbufs are strictly private and should stay private. >>> >>> Sbuf does not make any promises about how the string is stored >>> internally until you sbuf_finish() the buffer. >> >>sbuf did make this promise. =A0Since sbuf_data and sbuf_len are public >>accessor functions [...] > > Sbuf made no such promise, sbuf_data() and sbuf_len() are there > precisly to isolate the internals. Sorry, my wording was confused. I was meaning to say that, at the present, sbuf does not make any promises. > Amongst the original ideas was to have a multipart buffer to avoid > multiple realloc()/memcpy operations on buffer extends, and only > collapse the buffer at the end when the final size was known. =A0This > optimization has so far not been necessary. =A0Your API change would > make it impossible. Yes, that's a potential change that in fact can still be done. As I said, the only change is that the use of sbuf_data() then guarantees that the data is contiguous, instead of sbuf_finish() guaranteeing this. For an sbuf with an explicit drain, the buffer won't be growing, but will be drained instead. Thanks, matthew From owner-freebsd-arch@FreeBSD.ORG Wed Sep 8 17:38:46 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 7543F10656C1; Wed, 8 Sep 2010 17:38:46 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 020C08FC19; Wed, 8 Sep 2010 17:38:44 +0000 (UTC) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 244D73F61A; Wed, 8 Sep 2010 17:38:43 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.4/8.14.4) with ESMTP id o88Hcg4b067449; Wed, 8 Sep 2010 17:38:42 GMT (envelope-from phk@critter.freebsd.dk) To: mdf@FreeBSD.org From: "Poul-Henning Kamp" In-Reply-To: Your message of "Wed, 08 Sep 2010 10:10:06 MST." Date: Wed, 08 Sep 2010 17:38:42 +0000 Message-ID: <67448.1283967522@critter.freebsd.dk> Sender: phk@critter.freebsd.dk 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:38:46 -0000 In message , mdf@ FreeBSD.org writes: >I don't object to adding drains to userland. I want to. Cool, no disagreement there then. >I would assume that, if someone really wants this is userland before I >can get to this (and it is on my list of desired things to do) then >they can write the code first. ...or you make the simple interrim implementation that mandates that the buffer is big enough for any single operation performed on the sbuf (and overflow if it was not). In userland it is pretty much gratis to allocate a huge buffer, thanks to the wonder of Virtual Memory and JEmalloc. >> Which bit of "errno not relevant" in the description of -2 did >> you fail to notice ? =A0:-) > >Well, the specific error code is relevant, and I don't really want an >sbuf_set_error() function. For example, if my drain function is >SYSCTL_OUT, I want to preserve the error code that returned. Yeah, I guess for the kernel we may have to make the return -errno to allow that capture. Consider my prototype proposal changed as such: >= 0 # bytes flushed, <0 = -errno. >> Yes, but why would you want to ? =A0Normally private arguments are typed >> "void *" as they more often than not point to some structure, to >> which you can cast a void* directly, whereas uintptr_t requires a >> explicit cast. > >If my drain function is in userspace and writes to a file descriptor >I'd want it. Which is then the exceptional case where you would then have to cast it past a uintptr_t. The convention in all our code is that private arguments are void*, because that is generally the easiest to deal with, and we should stick to that. >Autoextend did not dictate the drain prototype. The autoextend drain >*is* an sbuf internal function -- note its existence in subr_sbuf.c. Yes it did. Any other drain function can be implemented with the prototype I provided you with. Only autoextend has a unavoidable need to fondle the sbuf internals. No other drain function will ever need to. >There may be other desired uses for a drain that don't just print to a >file/console/log, though those are the most likely. See the previously cited Gettys quote. You can always pass the necessary context through the private pointer, but you will never have a legitimate need to fondle the sbufs internals. And now for the tough one: >In the end I would like a One True Printf to bind them all[...] You and me brother, amen! 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. But this would require passing not only the varargs but also their types to the formatting function. It would be trivial for the compiler to insert a type specifying enum/bitmap before every argument, so that printf and any other varargs using functions knew what it was dealing with. I kind of like this idea, as it basically makes varargs typesafe, but obviously ISO-C think it is not kosher. However, this has nothing to do with the patches we are discussing, because they do not implement our desired OTP. 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. Poul-Henning -- 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. 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 From owner-freebsd-arch@FreeBSD.ORG Wed Sep 8 18:19:49 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 23EBB10656E5; Wed, 8 Sep 2010 18:19:49 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id DC26D8FC0A; Wed, 8 Sep 2010 18:19:48 +0000 (UTC) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id BB50C3F611; Wed, 8 Sep 2010 18:19:47 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.4/8.14.4) with ESMTP id o88IJlUT067572; Wed, 8 Sep 2010 18:19:47 GMT (envelope-from phk@critter.freebsd.dk) To: mdf@FreeBSD.org From: "Poul-Henning Kamp" In-Reply-To: Your message of "Wed, 08 Sep 2010 10:51:45 MST." Date: Wed, 08 Sep 2010 18:19:47 +0000 Message-ID: <67571.1283969987@critter.freebsd.dk> Sender: phk@critter.freebsd.dk 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 18:19:49 -0000 In message , mdf@ FreeBSD.org writes: >> 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? As I said: That we have worked around the problem rather than fixing it properly. I did a prototype somewhat along the lines of what you have done but abandonned it, because we would loose the printf argument checking that GCC provides. (See also the extensible userland printf I did). My main objection to your patches is that you exposes internals of sbufs for no good reason, if you fix that, along the lines we have discussed, I won't have that objection. Poul-Henning -- 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. From owner-freebsd-arch@FreeBSD.ORG Wed Sep 8 18:58:49 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 5D7CE10656E1 for ; Wed, 8 Sep 2010 18:58:49 +0000 (UTC) (envelope-from bakul@bitblocks.com) Received: from mail.bitblocks.com (mail.bitblocks.com [64.142.15.60]) by mx1.freebsd.org (Postfix) with ESMTP id 406E38FC1D for ; Wed, 8 Sep 2010 18:58:49 +0000 (UTC) Received: from bitblocks.com (localhost.bitblocks.com [127.0.0.1]) by mail.bitblocks.com (Postfix) with ESMTP id 96D5D5B81; Wed, 8 Sep 2010 11:58:48 -0700 (PDT) To: "Poul-Henning Kamp" In-reply-to: Your message of "Wed, 08 Sep 2010 17:38:42 -0000." <67448.1283967522@critter.freebsd.dk> References: <67448.1283967522@critter.freebsd.dk> Comments: In-reply-to "Poul-Henning Kamp" message dated "Wed, 08 Sep 2010 17:38:42 -0000." Date: Wed, 08 Sep 2010 11:58:48 -0700 From: Bakul Shah Message-Id: <20100908185848.96D5D5B81@mail.bitblocks.com> Cc: FreeBSD Arch Subject: printf 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 18:58:49 -0000 On Wed, 08 Sep 2010 17:38:42 -0000 "Poul-Henning Kamp" wrote: > > >In the end I would like a One True Printf to bind them all[...] > > You and me brother, amen! > > 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. But this would require passing not only the varargs > but also their types to the formatting function. If it was just printf/scanf family, one can perhaps hack gcc/clang to generate a default fmt string for each type, available with a `formatof' compile time function. Then one can do, for example, struct {int x, y;} z; printf("z=" formatof(z) "\n", z); printf("z->" formatof(&z) "\n", &z); But even for such a simple case most of us would disagree on just what formatof(z) should be. Should it be "%{%d, %d%}" or "%{x=%d, y=%d%}" or something else? Either would be enough for a compiler to check argument validity but there is no flexibility. Beyond that, an additional complication is in dealing with all the "optional" flags, width, precision, alternate formats etc. May be that can be dealt with by a set of auxiliary functions or a heavily overloading formatof. But I just don't think there exists a solution that is type safe, flexible and simple enough (the cure should not be worse than the disease). This is why I like the plan9 idea of allowing users to associate their own function with a given format char. [you don't get type safety but you get flexibility] > It would be trivial for the compiler to insert a type specifying > enum/bitmap before every argument, so that printf and any other > varargs using functions knew what it was dealing with. I kind of > like this idea, as it basically makes varargs typesafe, but obviously > ISO-C think it is not kosher. I suspect it is more that no one has come up with a model that is appealing enough. In any case they might be more amenable if a prototype exists. Face it, C is just a block structured assembly language! Personally I think the idea of extending C has jumped the shark long ago. From owner-freebsd-arch@FreeBSD.ORG Wed Sep 8 19:18:35 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 8B71410656D5 for ; Wed, 8 Sep 2010 19:18:35 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 4FD3E8FC12 for ; Wed, 8 Sep 2010 19:18:34 +0000 (UTC) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 11AF03F61A; Wed, 8 Sep 2010 19:18:34 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.4/8.14.4) with ESMTP id o88JIXDh067865; Wed, 8 Sep 2010 19:18:33 GMT (envelope-from phk@critter.freebsd.dk) To: Bakul Shah From: "Poul-Henning Kamp" In-Reply-To: Your message of "Wed, 08 Sep 2010 11:58:48 MST." <20100908185848.96D5D5B81@mail.bitblocks.com> Date: Wed, 08 Sep 2010 19:18:33 +0000 Message-ID: <67864.1283973513@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: FreeBSD Arch Subject: Re: printf 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 19:18:35 -0000 In message <20100908185848.96D5D5B81@mail.bitblocks.com>, Bakul Shah writes: >On Wed, 08 Sep 2010 17:38:42 -0000 "Poul-Henning Kamp" wrote: >If it was just printf/scanf family, one can perhaps hack >gcc/clang to generate a default fmt string for each type, >available with a `formatof' compile time function. Then one >can do, for example, > > struct {int x, y;} z; > printf("z=" formatof(z) "\n", z); > printf("z->" formatof(&z) "\n", &z); > >But even for such a simple case most of us would disagree on >just what formatof(z) should be. Indeed, not to mention that we still want to retain the padding/ width specifcation so things can be aligned nicely over multiple lines. There are conflicting issues here, but they all boil down to the look of the source-code. It is instructive to notice that the C++ "<<" stuff never really hit the mark except as a convenient debugging facility: Most people still fall back to *printf() for the actual formatting. If you survey other programming languages, the best they do is provide a default string representation, but seldom with any bells and whistles. And at least my attempts at a sensible advanced printf syntax has been anything but, making the lines sufficiently unreadable that I couldn't be bothered. I think the strength of the printf model is that the format spec is very compact, as soon as you embellish it, the model falls apart, and you suddenly need really strong compile-time checks to not make silly mistakes. (in the absense of typesafe varargs). If we can get over the disappointment of not being able to write the entire formatting statement in a single transparant source line, sbufs are an eminently workable solution, in that you can define your own formatting functions, like: sbuf_sockaddr(struct sbuf *, struct sockaddr *) and call that as much as you want, without getting bogged down in error checking. But: sbuf_cat(sb, "Client address: "); sbuf_sockaddr(sb, &sa); sbuf_cat(sb, "\n"); Does not compete with: printf("Client address: %{DWIM}\n", &sa); In any other way than by being feasible and available. >This is why I like the plan9 idea of allowing users to >associate their own function with a given format char. >[you don't get type safety but you get flexibility] We have that, see /usr/include/printf.h for userland. Problem is that the benefit from using it is quickly lost to not having any printf format-checking from the compiler anywhere. >Personally I think the idea of extending C has jumped the shark long ago. The problem is that we failed to maintain C as a cutting edge language and instead fell back to working around its shortcomings with all sorts of tools, from lint to Coverity. Now the same tools prevents us from updating C to have sensible contemporary features. Poul-Henning -- 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. From owner-freebsd-arch@FreeBSD.ORG Wed Sep 8 20:30:19 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 7FB7B10656A8 for ; Wed, 8 Sep 2010 20:30:19 +0000 (UTC) (envelope-from bakul@bitblocks.com) Received: from mail.bitblocks.com (bitblocks.com [64.142.15.60]) by mx1.freebsd.org (Postfix) with ESMTP id 50FDE8FC14 for ; Wed, 8 Sep 2010 20:30:19 +0000 (UTC) Received: from bitblocks.com (localhost.bitblocks.com [127.0.0.1]) by mail.bitblocks.com (Postfix) with ESMTP id 253A95B38; Wed, 8 Sep 2010 13:30:18 -0700 (PDT) To: "Poul-Henning Kamp" In-reply-to: Your message of "Wed, 08 Sep 2010 19:18:33 -0000." <67864.1283973513@critter.freebsd.dk> References: <67864.1283973513@critter.freebsd.dk> Comments: In-reply-to "Poul-Henning Kamp" message dated "Wed, 08 Sep 2010 19:18:33 -0000." Date: Wed, 08 Sep 2010 13:30:17 -0700 From: Bakul Shah Message-Id: <20100908203018.253A95B38@mail.bitblocks.com> Cc: FreeBSD Arch Subject: Re: printf 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 20:30:19 -0000 On Wed, 08 Sep 2010 19:18:33 -0000 "Poul-Henning Kamp" wrote: > In message <20100908185848.96D5D5B81@mail.bitblocks.com>, Bakul Shah writes: > >On Wed, 08 Sep 2010 17:38:42 -0000 "Poul-Henning Kamp" > wrote: > > >If it was just printf/scanf family, one can perhaps hack > >gcc/clang to generate a default fmt string for each type, > >available with a `formatof' compile time function. Then one > >can do, for example, > > > > struct {int x, y;} z; > > printf("z=" formatof(z) "\n", z); > > printf("z->" formatof(&z) "\n", &z); > > > >But even for such a simple case most of us would disagree on > >just what formatof(z) should be. > > Indeed, not to mention that we still want to retain the padding/ > width specifcation so things can be aligned nicely over multiple > lines. > > There are conflicting issues here, but they all boil down > to the look of the source-code. > > It is instructive to notice that the C++ "<<" stuff never really > hit the mark except as a convenient debugging facility: Most people > still fall back to *printf() for the actual formatting. > > If you survey other programming languages, the best they do is > provide a default string representation, but seldom with any > bells and whistles. See Common Lisp's format function. Even its bells and whistles have bells and whistles -- it may even be turing complete:-) http://www.gigamonkeys.com/book/a-few-format-recipes.html http://www.lispworks.com/documentation/HyperSpec/Body/22_c.htm But then most things are easier in Lisp/Scheme & a wrong format won't make your program crash. > And at least my attempts at a sensible advanced printf syntax > has been anything but, making the lines sufficiently unreadable > that I couldn't be bothered. Exactly. But some of us can't help attempting to do so! > I think the strength of the printf model is that the format spec > is very compact, as soon as you embellish it, the model falls apart, > and you suddenly need really strong compile-time checks to not make > silly mistakes. (in the absense of typesafe varargs). > > If we can get over the disappointment of not being able to write > the entire formatting statement in a single transparant source line, > sbufs are an eminently workable solution, in that you can define > your own formatting functions, like: > sbuf_sockaddr(struct sbuf *, struct sockaddr *) > and call that as much as you want, without getting bogged down in > error checking. > > But: > sbuf_cat(sb, "Client address: "); > sbuf_sockaddr(sb, &sa); > sbuf_cat(sb, "\n"); > > Does not compete with: > > printf("Client address: %{DWIM}\n", &sa); > > In any other way than by being feasible and available. > > >This is why I like the plan9 idea of allowing users to > >associate their own function with a given format char. > >[you don't get type safety but you get flexibility] > > We have that, see /usr/include/printf.h for userland. > > Problem is that the benefit from using it is quickly lost to not > having any printf format-checking from the compiler anywhere. How about somehow combining formatof with this? Hmm.... how about a new specifier that means the next argument is formatted with a function? For example, if we use & as a fmt function specifier, printf("Client address: %16&p\n", sa_fmt, &sa); or more generally printf("Client address: %16&" fmtof(&p) "\n", sa_fmt, &sa); Now fmtof is used for typechecking and advancing over the given argument but it is upto sa_fmt to convert sa to a string. Or how about visually embedding the function in the string? printf("Client address: %16" @sa_fmt "\n", &sa); The compiler would map this to the previous form. [Throwing this out just in case it triggers some new ideas] From owner-freebsd-arch@FreeBSD.ORG Wed Sep 8 22:22:59 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 6711B10656BA for ; Wed, 8 Sep 2010 22:22:59 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 2940B8FC14 for ; Wed, 8 Sep 2010 22:22:58 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 3C62F1FFC34; Wed, 8 Sep 2010 22:06:39 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 176F484525; Thu, 9 Sep 2010 00:06:39 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: mdf@FreeBSD.org References: <49781.1283888439@critter.freebsd.dk> Date: Thu, 09 Sep 2010 00:06:38 +0200 In-Reply-To: (mdf@freebsd.org's message of "Wed, 8 Sep 2010 08:43:40 -0700") Message-ID: <86k4mvlwk1.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Poul-Henning Kamp , 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 22:22:59 -0000 mdf@FreeBSD.org writes: > Regardless of what sbufs were originally designed to do, this seems > like a useful enhancement=20 If you want Emacs, you know where to find it... DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Wed Sep 8 22:57:41 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 D1A7710656B0; Wed, 8 Sep 2010 22:57:41 +0000 (UTC) (envelope-from gordon.tetlow@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 878998FC13; Wed, 8 Sep 2010 22:57:41 +0000 (UTC) Received: by iwn34 with SMTP id 34so502228iwn.13 for ; Wed, 08 Sep 2010 15:57:40 -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; bh=B83+zSvSEuZ/qbMNYGDoX9kUVwY/aGQPg93ITu+QwC4=; b=VIbUiTSrHIykHOFW5usY9/Iljtt2wsbq11erD4S1JeXaq3vtyId9WYB1F1QtbxZ+N6 6ggEx8gWpppYZiu6ozaVmFpUw8Sf/HyuVoL6/Fm3V1OpMCCn9ltBPzo/n2USGkDuW7Gi i7N+6aBiFVTuezX8BIzWv4O+ixjEOK//b4IqI= 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; b=e/AMUBhO96WjbqWIx4BjjJL5MQCDy2yRzTDZ4mq9K9eD1DzabGoKpNS7JSkY7xQtQi lx0P25Toh6wXbF4cd/xJamzDKsKQtUOUxanNUSn2/utLqOZfJztBHy3YpSNY4qB/DvjN ECMTd3+mqeSUUvJCHS1EJvYnEJgdu+NIUKTYw= MIME-Version: 1.0 Received: by 10.231.173.144 with SMTP id p16mr10469932ibz.108.1283985343927; Wed, 08 Sep 2010 15:35:43 -0700 (PDT) Sender: gordon.tetlow@gmail.com Received: by 10.231.156.78 with HTTP; Wed, 8 Sep 2010 15:35:43 -0700 (PDT) In-Reply-To: <67049.1283963396@critter.freebsd.dk> References: <67049.1283963396@critter.freebsd.dk> Date: Wed, 8 Sep 2010 15:35:43 -0700 X-Google-Sender-Auth: qxdUkGie14kDmUWe5g0yMYelUl8 Message-ID: From: Gordon Tetlow To: Poul-Henning Kamp Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: mdf@freebsd.org, 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 22:57:42 -0000 On Wed, Sep 8, 2010 at 9:29 AM, Poul-Henning Kamp wrote: > In message , > mdf@ > FreeBSD.org writes: > >> For one thing, sbuf is not a kernel facility, it is a general purpose > >> string editing library which is also used outside FreeBSD. If > >> we add the drain facility it should work in both userland and kernel. > > > >Given that sys/sbuf.h is included in 100+ kernel files and 4 > >user-space files, [...] > > That is probably more an indication that our userland is largely > unchanged from 1995, whereas as everybody loves to hack up the > kernel :-) The various people who have told me they adopted sbufs > have been very happy with them in userland. I would think that is more likely a result of the only documentation I see for sbuf always refers to kernel implementation (sbuf(9), I don't see any documentation for sbuf(3). Can you give some pointers? I've always hated string manipulation in C, if I can find another way to do it, I'm all for it. Gordon From owner-freebsd-arch@FreeBSD.ORG Wed Sep 8 23:09:18 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 E3D0C106566B for ; Wed, 8 Sep 2010 23:09:18 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 9160E8FC12 for ; Wed, 8 Sep 2010 23:09:18 +0000 (UTC) Received: by gxk24 with SMTP id 24so423202gxk.13 for ; Wed, 08 Sep 2010 16:09:17 -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=o/out9nuBAGVMFyGw+crSe15++WDmzKzM3cAYU7oKj4=; b=JQB9YEKaQect5hp8W/ZcItj7b0T31ypYBwaLHoXickysoo1BoGww+m5v+L/53WaeCN IH7MSqwOlJzoxr/gpoFDroctk8Ws+/0GIv36ZWXf526J8SOasKW51Y+Unz0CCNSzeQFa QSYyEJ/sI8OrJRJZ7pV2T6A0RDWsvUGzBDPHs= 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=Z1cZ4EpcBsrUQ3FbX79hY9Vd8jbIvXLTQTy8kc/jbReHpxyu1RRDXJm/ny/4UTP6Hc 2ppIavuAAijVa0tdsLwNogufTQEpWkc3kooAJmJhPvlz1rgY//2145sFKrASI5r0Q1fT 6pK2E8MIGzIH9Nd1aSDNECZgcbSLjhBFzT2Gg= MIME-Version: 1.0 Received: by 10.100.235.10 with SMTP id i10mr589275anh.1.1283987355059; Wed, 08 Sep 2010 16:09:15 -0700 (PDT) Sender: mdf356@gmail.com Received: by 10.100.126.20 with HTTP; Wed, 8 Sep 2010 16:09:14 -0700 (PDT) In-Reply-To: References: <67049.1283963396@critter.freebsd.dk> Date: Wed, 8 Sep 2010 16:09:14 -0700 X-Google-Sender-Auth: ET7Uk2_GF8BoVH4X_jNeP200K_I Message-ID: From: mdf@FreeBSD.org To: Gordon Tetlow Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Poul-Henning Kamp , 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 23:09:19 -0000 On Wed, Sep 8, 2010 at 3:35 PM, Gordon Tetlow wrote: > On Wed, Sep 8, 2010 at 9:29 AM, Poul-Henning Kamp > wrote: >> >> In message , >> mdf@ >> FreeBSD.org writes: >> >> For one thing, sbuf is not a kernel facility, it is a general purpose >> >> string editing library which is also used outside FreeBSD. =A0 If >> >> we add the drain facility it should work in both userland and kernel. >> > >> >Given that sys/sbuf.h is included in 100+ kernel files and 4 >> >user-space files, [...] >> >> That is probably more an indication that our userland is largely >> unchanged from 1995, whereas as everybody loves to hack up the >> kernel :-) =A0The various people who have told me they adopted sbufs >> have been very happy with them in userland. > > I would think that is more likely a result of the only documentation I se= e > for sbuf always refers to kernel implementation (sbuf(9), I don't see any > documentation for sbuf(3). Can you give some pointers? I've always hated > string manipulation in C, if I can find another way to do it, I'm all for > it. The sbuf(9) man page describes the library well. It's in lib/libsbuf, so link a userland application with -lsbuf. Cheers, matthew From owner-freebsd-arch@FreeBSD.ORG Wed Sep 8 23:15:00 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 AB91610656E4 for ; Wed, 8 Sep 2010 23:15:00 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 4D79F8FC15 for ; Wed, 8 Sep 2010 23:14:59 +0000 (UTC) Received: by gyg4 with SMTP id 4so434863gyg.13 for ; Wed, 08 Sep 2010 16:14:59 -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:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=/GOavMFT9YXSqRRfRHTF8CaGPU8TJLskbnrajVWJpBw=; b=N3xXxENfDoOcu5V3/iboGYWgdXo02q876UJY0N2X/qYZMUZRezLkw3HUVIhVZ1vWGX 3Ehp+Hv1XmhzymhUnp04IViNJsgvJPYz2UmPRd5Eq/996sjg7gHAfmzxctsDhFbVgIuk kz8wKnDGI+SuoJi5qjPV/cH6Ufkmodkdae9mM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; b=n3dnnX8TcCOqwJAWZ1fNESDDYHcNMNNjjKCgx/6Gy1BNHnhtjTbiWpcQg8bqZ9TzAx Yrl84Tp/SWZ1dqygEZ8qsvGGKxXHlb8k7LhkPqsYBXvE+HN+pfQPDjteqPN2hENBMJHL XACpiRV+svzRzqMXcScjoNmgk8BELnO+bI0EQ= MIME-Version: 1.0 Received: by 10.101.193.17 with SMTP id v17mr1017942anp.206.1283987699328; Wed, 08 Sep 2010 16:14:59 -0700 (PDT) Sender: mdf356@gmail.com Received: by 10.100.126.20 with HTTP; Wed, 8 Sep 2010 16:14:59 -0700 (PDT) Date: Wed, 8 Sep 2010 16:14:59 -0700 X-Google-Sender-Auth: A6aXJGpQ046wRrmUzBOKMBamPnA Message-ID: From: mdf@FreeBSD.org To: FreeBSD Arch , Poul-Henning Kamp Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: Extending sbufs with a drain, take 2 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 23:15:00 -0000 After the discussion here with phk, I have reworked my patches. If I've misunderstood the intent, I welcome corrections. Do these patches seem reasonable? --- Refactor sbuf code so that most uses of sbuf_extend() are in a new sbuf_put_byte(). This makes it easier to add drain functionality when a buffer would overflow as there are fewer code points. http://people.freebsd.org/~mdf/0001-Refactor-sbuf-code-so-that-most-uses-of-sbuf_extend-.patch --- Fix small errors in the sbuf(9) man page. http://people.freebsd.org/~mdf/0002-Fix-small-errors-in-the-sbuf-9-man-page.patch --- Add drain functionality to sbufs. The drain is a function that is called when the sbuf internal buffer is filled. For kernel sbufs with a drain, the internal buffer will never be expanded. For userland sbufs with a drain, the internal buffer may still be expanded by sbuf_[v]printf(3). http://people.freebsd.org/~mdf/0003-Add-drain-functionality-to-sbufs.-The-drain-is-a-fun.patch --- Add a drain function for struct sysctl_req, and use it for a variety of handlers that had to do awkward things to get a large enough FIXEDLEN buffer. http://people.freebsd.org/~mdf/0004-Add-a-drain-function-for-struct-sysctl_req-and-use-i.patch --- Fix an incorrect use of sbuf_overflowed() after a call to sbuf_finish(). http://people.freebsd.org/~mdf/0005-Fix-an-incorrect-use-of-sbuf_overflowed-after-a-call.patch --- Replace sbuf_overflowed() with sbuf_error(), which returns any error code associated with overflow or with the drain function. http://people.freebsd.org/~mdf/0006-Replace-sbuf_overflowed-with-sbuf_error-which-return.patch Thanks, matthew From owner-freebsd-arch@FreeBSD.ORG Thu Sep 9 07:27:01 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 1C4DE10656CC; Thu, 9 Sep 2010 07:27:01 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id A13DB8FC14; Thu, 9 Sep 2010 07:27:00 +0000 (UTC) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 418843F61A; Thu, 9 Sep 2010 07:26:59 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.4/8.14.4) with ESMTP id o897QxSu085036; Thu, 9 Sep 2010 07:26:59 GMT (envelope-from phk@critter.freebsd.dk) To: mdf@FreeBSD.org From: "Poul-Henning Kamp" In-Reply-To: Your message of "Wed, 08 Sep 2010 16:14:59 MST." Date: Thu, 09 Sep 2010 07:26:59 +0000 Message-ID: <85035.1284017219@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: FreeBSD Arch Subject: Re: Extending sbufs with a drain, take 2 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: Thu, 09 Sep 2010 07:27:01 -0000 In message , mdf@ FreeBSD.org writes: >After the discussion here with phk, I have reworked my patches. Much better, but still not there IMO. >Refactor sbuf code so that most uses of sbuf_extend() are in a new >sbuf_put_byte(). This makes it easier to add drain functionality when a >buffer would overflow as there are fewer code points. > >http://people.freebsd.org/~mdf/0001-Refactor-sbuf-code-so-that-most-uses-of-sbuf_extend-.patch I would probably have made sbuf_put_byte() a proper sbuf function and added a one-line wrapper function for the benefit of kvprintf(), rather than loose type-safety for all the other functions. >Fix small errors in the sbuf(9) man page. > >http://people.freebsd.org/~mdf/0002-Fix-small-errors-in-the-sbuf-9-man-page.patch Good catch. >Add drain functionality to sbufs. The drain is a function that is >called when the sbuf internal buffer is filled. For kernel sbufs with a >drain, the internal buffer will never be expanded. For userland sbufs >with a drain, the internal buffer may still be expanded by >sbuf_[v]printf(3). > >http://people.freebsd.org/~mdf/0003-Add-drain-functionality-to-sbufs.-The-drain-is-a-fun.patch I'm not sure I can see the point of the flags argument. I would just have sbuf_finish() keep calling the drain until everything is gone, that is what is going to happen for any sbuf_foo() call if the drain function only picks one byte at a time. If you need any "magic EOF" processing, you can do that from the main code-path after calling sbuf_finish(), since you have already stipulated: ]] +The returned drained length cannot be zero. In regards to manpage: ]] @@ -311,6 +351,9 @@ functions return the actual string and its length, respectively; ]] .Fn sbuf_data ]] only works on a finished ]] .Fa sbuf . ]] +Neither function should be used on an ]] +.Fa sbuf ]] +with an attached drain. ]] .Fn sbuf_done ]] returns non-zero if the ]] .Fa sbuf I thought we agreed that sbuf_len() returned #undrained_bytes ? Instead of spreading it out over the text you should add a new section where you describe the workings of drains, including details such as the "len=2" for char-by-char drain, return values and requirements of a drain fucntion, and list the functions that cannot be used on these sbufs. (like sbuf_trim() ?) sbuf_set_drain(): ----------------- You assert that the drain function can not be overwritten, that seems excessive to me ? Why wouldn't that be allowed ? I would only assert that to change in and out of a drain mode the sbuf must be empty: if ((s->drain_func == NULL && func != NULL) || (s->drain_func != NULL && func == NULL)) assert(s->s_len == 0); >Add a drain function for struct sysctl_req, and use it for a variety >of handlers that had to do awkward things to get a large enough >FIXEDLEN buffer. > >http://people.freebsd.org/~mdf/0004-Add-a-drain-function-for-struct-sysctl_req-and-use-i.patch I sort of think sbuf_sysctl_drain(), sbuf_new_for_sysctl() belongs in kern_sysctl.c more than in subr_sbuf.c, mostly in view of the shared kernel/userland aspect of sbufs. I Love patches which do remove twice as much code as they add: 12 files changed, 105 insertions(+), 196 deletions(-) >Fix an incorrect use of sbuf_overflowed() after a call to sbuf_finish(). > >http://people.freebsd.org/~mdf/0005-Fix-an-incorrect-use-of-sbuf_overflowed-after-a-call.patch > >--- > >Replace sbuf_overflowed() with sbuf_error(), which returns any error >code associated with overflow or with the drain function. > >http://people.freebsd.org/~mdf/0006-Replace-sbuf_overflowed-with-sbuf_error-which-return.patch Now that sbuf_finish() returns the error, most applications should not need to sbuf_finish()/sbuf_error() at all. I can see a valid use for sbuf_error() in this sort of code: sb = sbuf_new(...) for (really long and tortous loop) { sbuf_bla(sb, ....) ... if (sbuf_error(sb)) break; /* Don't waste time if we lost already */ } But the normal case now should just be to check the return of sbuf_finish(). -- 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. From owner-freebsd-arch@FreeBSD.ORG Thu Sep 9 08:01:20 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 7AC3A10656C6 for ; Thu, 9 Sep 2010 08:01:20 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id ABBD48FC2B for ; Thu, 9 Sep 2010 08:01:19 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id LAA27197 for ; Thu, 09 Sep 2010 11:01:17 +0300 (EEST) (envelope-from avg@freebsd.org) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1Otc4K-0004MZ-Ut for freebsd-arch@FreeBSD.org; Thu, 09 Sep 2010 11:01:17 +0300 Message-ID: <4C88944C.5060603@freebsd.org> Date: Thu, 09 Sep 2010 11:01:16 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.8) Gecko/20100822 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: freebsd-arch@freebsd.org References: <4C4DB2B8.9080404@freebsd.org> In-Reply-To: <4C4DB2B8.9080404@freebsd.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: amd64: change VM_KMEM_SIZE_SCALE to 1? 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: Thu, 09 Sep 2010 08:01:20 -0000 on 26/07/2010 19:07 Andriy Gapon said the following: > > Anyone knows any reason why VM_KMEM_SIZE_SCALE on amd64 should not be set to 1? > I mean things potentially breaking, or some unpleasant surprise for an > administrator/user... So, after having the discussion, what is our collective conclusion? a) Go for it! or b) Don't do it, fool! or c) Let's wait another year... Thanks! -- Andriy Gapon From owner-freebsd-arch@FreeBSD.ORG Thu Sep 9 08:03:54 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 3AD6710656A4 for ; Thu, 9 Sep 2010 08:03:54 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 5FDCE8FC17 for ; Thu, 9 Sep 2010 08:03:52 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id LAA27243; Thu, 09 Sep 2010 11:03:50 +0300 (EEST) (envelope-from avg@freebsd.org) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1Otc6n-0004Mt-66; Thu, 09 Sep 2010 11:03:49 +0300 Message-ID: <4C8894E4.2030804@freebsd.org> Date: Thu, 09 Sep 2010 11:03:48 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.8) Gecko/20100822 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Peter Wemm References: <4C4DB2B8.9080404@freebsd.org> <4C4DD1AA.3050906@freebsd.org> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-arch@freebsd.org Subject: Re: amd64: change VM_KMEM_SIZE_SCALE to 1? 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: Thu, 09 Sep 2010 08:03:54 -0000 on 26/07/2010 22:29 Peter Wemm said the following: > > That hard limit of 512G of physical ram doesn't seem so distant anymore.. I was reviewing this thread and got curious about this statement. What is this limit? Where does it come from? -- Andriy Gapon From owner-freebsd-arch@FreeBSD.ORG Thu Sep 9 09:09:38 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 8D44C10656EF for ; Thu, 9 Sep 2010 09:09:38 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 0469B8FC1B for ; Thu, 9 Sep 2010 09:09:37 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id o898QwQq047788 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Sep 2010 11:26:58 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id o898QvB6005481; Thu, 9 Sep 2010 11:26:57 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id o898Qv7L005480; Thu, 9 Sep 2010 11:26:57 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 9 Sep 2010 11:26:57 +0300 From: Kostik Belousov To: Andriy Gapon Message-ID: <20100909082657.GJ2465@deviant.kiev.zoral.com.ua> References: <4C4DB2B8.9080404@freebsd.org> <4C4DD1AA.3050906@freebsd.org> <4C8894E4.2030804@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="LQAwcd5tHl0Qlnzi" Content-Disposition: inline In-Reply-To: <4C8894E4.2030804@freebsd.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-2.2 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_50, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-arch@freebsd.org Subject: Re: amd64: change VM_KMEM_SIZE_SCALE to 1? 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: Thu, 09 Sep 2010 09:09:38 -0000 --LQAwcd5tHl0Qlnzi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Sep 09, 2010 at 11:03:48AM +0300, Andriy Gapon wrote: > on 26/07/2010 22:29 Peter Wemm said the following: > >=20 > > That hard limit of 512G of physical ram doesn't seem so distant anymore= .. >=20 > I was reviewing this thread and got curious about this statement. > What is this limit? Where does it come from? I do not think that such limit is enforced by hardware. In the recent Intel x86 sw architecture specification, there is a statement (vol 3a, 4.1.4): CPUID.80000008H:EAX[7:0] reports the physical-address width supported by the processor. (For processors that do not support CPUID function 80000008H, the width is generally 36 if CPUID.01H:EDX.PAE [bit 6] =3D 1 and 32 otherwi= se.) This width is referred to as MAXPHYADDR. MAXPHYADDR is at most 52. I suspect that "512GB" might refer to the current direct map sizing in the amd64 pmap module. The direct map is provided by single entry in pml4 table, that allows to map 512GB. --LQAwcd5tHl0Qlnzi Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkyImlEACgkQC3+MBN1Mb4hn7ACeLy82tA2YE49RoolzC/hfiqrD kfAAn2cK7Dz0xWpl+YIczEQTrqnH/tEO =l3CR -----END PGP SIGNATURE----- --LQAwcd5tHl0Qlnzi-- From owner-freebsd-arch@FreeBSD.ORG Thu Sep 9 09:56:51 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 4EACF1065670 for ; Thu, 9 Sep 2010 09:56:51 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id CAFDE8FC1C for ; Thu, 9 Sep 2010 09:56:50 +0000 (UTC) Received: by bwz20 with SMTP id 20so1140140bwz.13 for ; Thu, 09 Sep 2010 02:56:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=Um41vbwON5+ucTyd+phwcr2mi22CZqXNf2YcT5GY3As=; b=d6ry63gIYjOzo28o0iC7tLrKu8+wL8OXPX5X5mlsH9azHAYJPE7iVS05Hv/d7wCLWO WhjjmaI5pIKmE1tdFvcvk24TE60GC7VGz41e0Hy1ywgQNwSjwjXcGdGPKFGmT7JTdegv 6P6IneqtL8ou0++vh2Y40bE5FyorE9nHm3Lu8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=QYImHmUGc4Ux3VJqkKSKkdNMQvYIazBcKsjWWh0m7swL0wcvdjVcCzYVPdmWi+EgCW K74LRczzi32H/CVx0t2wOBLYtBElQAE592HgIeVUOwE+6YyGyUYvLKeVDagzD9hJOq3h OJ7WTSZCRp2KWJxdeWZljoBJ6gncrwt4b0uAA= Received: by 10.204.60.145 with SMTP id p17mr369610bkh.56.1284026209320; Thu, 09 Sep 2010 02:56:49 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id f16sm880621bkd.16.2010.09.09.02.56.47 (version=SSLv3 cipher=RC4-MD5); Thu, 09 Sep 2010 02:56:48 -0700 (PDT) Sender: Alexander Motin Message-ID: <4C88AF4D.4020903@FreeBSD.org> Date: Thu, 09 Sep 2010 12:56:29 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.24 (X11/20100402) MIME-Version: 1.0 To: "Cherry G. Mathew" References: <4C0C1AE4.8050807@FreeBSD.org> <4C864FFD.6020409@zyx.in> <4C868A43.6080405@FreeBSD.org> <4C872AA4.5020906@zyx.in> <4C8738DA.80604@FreeBSD.org> <4C88AC08.7070502@zyx.in> In-Reply-To: <4C88AC08.7070502@zyx.in> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-arch@freebsd.org Subject: Re: [resend] Re: RFC: New event timers infrastructure 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: Thu, 09 Sep 2010 09:56:51 -0000 Cherry G. Mathew wrote: > To summarise, > > My two concerns were: > I) > a) If there is a non-optional device specific callback (like a timer > isr) tied to specific timer on a vendor board > b) a "generic" non-device specific callback that uses the ET framework > and acquires the timer in "a)" before the isr/callback in "a)" could > obtain it. > > how can the API ensure that this scenario: > > i) doesn't happen > or > ii) can be subsequently rectified Using event timer (unlike time counter) most likely means programming it. Without enough complicated midlayer two consumers won't be able to use single timer, unless it ticks at fixed frequency and doesn't allow any programming. For this reason I wasn't expecting any sharing. We could extend API to allow shared event timer usage, but in that case only one consumer should control it, while all other's just receive these events and trust that timer programmed as they expect. At this moment I don't see practical reason where such functionality would be needed. Do you have some? > AND > II) > Did the api need to be fleshed out separately of timertc.h ? API is in stage of development and was changes few times since originally created. May be some ideas, like yours, could affect it again. -- Alexander Motin From owner-freebsd-arch@FreeBSD.ORG Thu Sep 9 09:42:37 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 AE5B61065700; Thu, 9 Sep 2010 09:42:37 +0000 (UTC) (envelope-from cherry@zyx.in) Received: from reagan.nswebhost.com (reagan.nswebhost.com [64.22.87.10]) by mx1.freebsd.org (Postfix) with ESMTP id 063608FC23; Thu, 9 Sep 2010 09:42:37 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=zyx.in; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-Antivirus:X-Antivirus-Status; b=AGmLDb4Y2mX6Bcgv8wHlAq0Ck8jOllmzQZM7746WVB9RuaqFcTd6J+0jl9S6zOJZTVO9vhTiMnpv6CSjewEkobc2EG/ZdI01bypiOaFbnxNuBb9tFiyDKuCe2tz/BvMt; Received: from [117.241.57.119] (helo=[127.0.0.1]) by reagan.nswebhost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1OtdeM-0002Yg-Vu; Thu, 09 Sep 2010 04:42:35 -0500 Message-ID: <4C88AC08.7070502@zyx.in> Date: Thu, 09 Sep 2010 15:12:32 +0530 From: "Cherry G. Mathew" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.8) Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Alexander Motin References: <4C0C1AE4.8050807@FreeBSD.org> <4C864FFD.6020409@zyx.in> <4C868A43.6080405@FreeBSD.org> <4C872AA4.5020906@zyx.in> <4C8738DA.80604@FreeBSD.org> In-Reply-To: <4C8738DA.80604@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 100908-1, 09/08/2010), Outbound message X-Antivirus-Status: Clean X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - reagan.nswebhost.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - zyx.in X-Mailman-Approved-At: Thu, 09 Sep 2010 11:07:58 +0000 Cc: freebsd-arch@freebsd.org Subject: Re: [resend] Re: RFC: New event timers infrastructure 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: Thu, 09 Sep 2010 09:42:37 -0000 Dear Alexander, On 9/8/2010 12:48 PM, Alexander Motin wrote: > > If you wish to work with specific event timer - you can ask et_find() to > give one to you, specifying it's name, and if it is not yet busy - use > if freely for whatever you want. > And if it is busy ? I have in mind non system timers, like stuff that comes on add-on boards, that can be exported timeret.h and interrupt the CPU. Would exporting such a timer prevent the onboard devices from utilising that specific timer function because its callback was busy ? >>> There is not so much hardware that can be used as both time counter and >>> event timer. For example, on x86: >>> - i8254 can do both, but preferably not at the same time and never both >>> with event timer in one-shot mode; >>> - RTC - only event timer; >>> - LAPIC - only event timer; >> >> An ideal opportunity to implement: >> >> { >> mtx_lock_spin(&clock_lock); >> softcounter++; >> mtx_unlock_spin(&clock_lock); >> } > > :) It will give you terrible precision or huge interrupt rate. > Indeed, but the abstraction could still be maintained. More practically, a flag could take care of this (TC_COUNTER_NONE or whatever. ) >> >> I think the key thing I'm worried about here is consumer order. Is there >> a way in which this can be queried/set by consumers ? I imagine a >> generic scheduler would abstract this decision away from consumers as a >> "scheduling policy". > > Are you talking about callback order in case of two simultaneous events? > because if events are not scheduled as simultaneous (up to 64-bit > precision) they could be called respectively to that order. Question is > about interrupt latency or what? > To summarise, My two concerns were: I) a) If there is a non-optional device specific callback (like a timer isr) tied to specific timer on a vendor board b) a "generic" non-device specific callback that uses the ET framework and acquires the timer in "a)" before the isr/callback in "a)" could obtain it. how can the API ensure that this scenario: i) doesn't happen or ii) can be subsequently rectified AND II) Did the api need to be fleshed out separately of timertc.h ? This is more of a political question that I don't care much about. Cheers, -- cherry From owner-freebsd-arch@FreeBSD.ORG Thu Sep 9 17:46:03 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 3177110656AB for ; Thu, 9 Sep 2010 17:46:03 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id D3FA98FC14 for ; Thu, 9 Sep 2010 17:46:02 +0000 (UTC) Received: by gyg4 with SMTP id 4so881611gyg.13 for ; Thu, 09 Sep 2010 10:46:02 -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; bh=5e6wx0jWNcQWEVbqZLcn+/Cb9/S3FFRjVH6YU9ddxPI=; b=qwRW0oUMKH1Pco05QOxfDHw2/wvcHi557mfK7iF/pq1oR7Mkt76/z0FOe2gGMJkjs9 GMtTXgEktGvfyAtvudsRlPX8y+yeXewxJyuPCXDRubM7XkfxW949POT9g9GvqssQD34m BjRn2muzhjhvc6LHnva6FB9x2Lf8os6lcV4qU= 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; b=yAz8u5/HvFRANqzJHQjABebFKnVRlWEzZGjYNDtfFvgjcouSk9Gn91cb+KveEi+COG 2AcH8h+geLVYpynrP9WVs+40fLGaySudhLYHYtp7G4AFhTByEXG3bQZxXw6OVcw1qh8x NLObocR0dJ2iTQ6ZO8nCGL+leflX2qpAInIP0= MIME-Version: 1.0 Received: by 10.101.209.31 with SMTP id l31mr421260anq.191.1284054359828; Thu, 09 Sep 2010 10:45:59 -0700 (PDT) Sender: mdf356@gmail.com Received: by 10.100.126.20 with HTTP; Thu, 9 Sep 2010 10:45:59 -0700 (PDT) In-Reply-To: <85035.1284017219@critter.freebsd.dk> References: <85035.1284017219@critter.freebsd.dk> Date: Thu, 9 Sep 2010 10:45:59 -0700 X-Google-Sender-Auth: Xmszr27iC8BWHSVzzGF8cV8mUMU Message-ID: From: mdf@FreeBSD.org To: Poul-Henning Kamp Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Arch Subject: Re: Extending sbufs with a drain, take 2 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: Thu, 09 Sep 2010 17:46:03 -0000 Thank you very much for your continued input. I have incorporated all these ideas and I am committing the patches as I update them and test them. On Thu, Sep 9, 2010 at 12:26 AM, Poul-Henning Kamp wrote: >>Replace sbuf_overflowed() with sbuf_error(), which returns any error >>code associated with overflow or with the drain function. >> >>http://people.freebsd.org/~mdf/0006-Replace-sbuf_overflowed-with-sbuf_error-which-return.patch > > Now that sbuf_finish() returns the error, most applications should > not need to sbuf_finish()/sbuf_error() at all. Right. There were 16 uses in the entire tree (all in the kernel). Several of these were in error; that is checking sbuf_overflowed() after an sbuf_finish(). These uses I fixed to check the return code from sbuf_finish(). I believe 5 were used to determine if the static buffer for sysctl was too small; these uses are removed in my patch. The remaining uses are to check that the data fits in the static sized buffer, e.g. MAXPATHLEN for audit, 1024 bytes for some ioctls, etc. Again, thanks for all your help. One question about the printf expanded args in xprintf.c: Does the extension framework allow for multiple character conversion specifiers? I.e. I see that you added a sample %V and %H and %T in the original version. Could this framework allow a %{} specifier or is it assumed that conversions are a single character (possibly with modifiers)? Thanks, matthew From owner-freebsd-arch@FreeBSD.ORG Thu Sep 9 21:41:25 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 19C521065674; Thu, 9 Sep 2010 21:41:25 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id CEC648FC13; Thu, 9 Sep 2010 21:41:24 +0000 (UTC) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id A843D3F5C3; Thu, 9 Sep 2010 21:41:23 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.4/8.14.4) with ESMTP id o89Kwm4V001726; Thu, 9 Sep 2010 20:58:48 GMT (envelope-from phk@critter.freebsd.dk) To: mdf@FreeBSD.org From: "Poul-Henning Kamp" In-Reply-To: Your message of "Thu, 09 Sep 2010 10:45:59 MST." Date: Thu, 09 Sep 2010 20:58:48 +0000 Message-ID: <1725.1284065928@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: FreeBSD Arch Subject: Re: Extending sbufs with a drain, take 2 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: Thu, 09 Sep 2010 21:41:25 -0000 In message , mdf@ FreeBSD.org writes: >One question about the printf expanded args in xprintf.c: > >Does the extension framework allow for multiple character conversion >specifiers? I belive it indexes with a single char into an array right now, but that is just a matter of string parsing, {...} is not hard to do. Bear in mind that using extensions force you to disable the GCC format checks, a heavy cost to bear. Also bear in mind that any work on this should keep an eye on, and if at all possible collaborate with GLIBC for maximum compatibility. -- 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. From owner-freebsd-arch@FreeBSD.ORG Thu Sep 9 21:46:42 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 BCDDD1065697 for ; Thu, 9 Sep 2010 21:46:42 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 0B9338FC18 for ; Thu, 9 Sep 2010 21:46:40 +0000 (UTC) Received: by ywt2 with SMTP id 2so983990ywt.13 for ; Thu, 09 Sep 2010 14:46:40 -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; bh=LM3F0Z1wt6BG9jKCJZ/KumhwJSa+y9GeaH/7CZ7/5Ac=; b=KE3+R8sDlPaHH25ozGF4ZMX4Pmo7XAIZhnQJ0FxBroWdVqGfjELbGVa6KrBOU0wtfI nxyBBMJp6KCOEp2AQauNKlOkL9oyErxgk4sfR0Z9njnD5uHUuDJUFAPaCoGlKRmIsHaA n5eQtfh6CZ3uzI138qVNRkkblbVRp9VQ3dagg= 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; b=J4/2jqRbNA2RB+GF1PlpJR70+Cixylr2evyX4FztPio+Tq8lC54r3U/6+EFDt9NRJA zQYEY6KJgM8Aqj57c3pl8C9rm7MfNND0utTEJU7lv+1ikTfcRrH4izR4nlDURrKQwrEU bi7j+iTaC6FJ1tcBoSvFgh4DjVJIpCgDNC394= MIME-Version: 1.0 Received: by 10.100.209.15 with SMTP id h15mr811952ang.232.1284068800147; Thu, 09 Sep 2010 14:46:40 -0700 (PDT) Sender: mdf356@gmail.com Received: by 10.100.126.20 with HTTP; Thu, 9 Sep 2010 14:46:40 -0700 (PDT) In-Reply-To: <1725.1284065928@critter.freebsd.dk> References: <1725.1284065928@critter.freebsd.dk> Date: Thu, 9 Sep 2010 14:46:40 -0700 X-Google-Sender-Auth: qLCI8LOi2EUsqUKpkwRJTx7LbJM Message-ID: From: mdf@FreeBSD.org To: Poul-Henning Kamp Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Arch Subject: Re: Extending sbufs with a drain, take 2 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: Thu, 09 Sep 2010 21:46:42 -0000 On Thu, Sep 9, 2010 at 1:58 PM, Poul-Henning Kamp wrote: > In message , mdf@ > FreeBSD.org writes: > >>One question about the printf expanded args in xprintf.c: >> >>Does the extension framework allow for multiple character conversion >>specifiers? > > I belive it indexes with a single char into an array right now, but > that is just a matter of string parsing, {...} is not hard to do. > > Bear in mind that using extensions force you to disable the GCC > format checks, a heavy cost to bear. Conveniently, we already have code at Isilon that modifies the gcc format checks to look for the %{} format. I saved an email with info about Clang's format checks so I may be able to do something there too. > Also bear in mind that any work on this should keep an eye on, and if > at all possible collaborate with GLIBC for maximum compatibility. Yes, this is something I don't know anything about. I'll look into it. Thanks, matthew