From owner-svn-src-all@FreeBSD.ORG Fri Feb 17 09:44:32 2012 Return-Path: Delivered-To: svn-src-all@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 90F89106566B; Fri, 17 Feb 2012 09:44:32 +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 85ED48FC0C; Fri, 17 Feb 2012 09:44:29 +0000 (UTC) Received: from porto.starpoint.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 LAA03411; Fri, 17 Feb 2012 11:44:16 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1RyKMR-0007Y7-Ik; Fri, 17 Feb 2012 11:44:15 +0200 Message-ID: <4F3E2150.8030504@FreeBSD.org> Date: Fri, 17 Feb 2012 11:43:44 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0) Gecko/20120202 Thunderbird/10.0 MIME-Version: 1.0 To: Marcel Moolenaar , "Kenneth D. Merry" , Julian Elischer References: <201202160511.q1G5BZNk099785@svn.freebsd.org> <20120216181210.K1423@besplex.bde.org> <4F3CC40D.4000307@freebsd.org> <4F3CC5C4.7020501@FreeBSD.org> <4F3CC8A5.3030107@FreeBSD.org> <20120216174758.GA64180@nargothrond.kdm.org> <20120217053341.R1256@besplex.bde.org> <20120217000846.GA7641@nargothrond.kdm.org> <4F3D9D03.6020507@FreeBSD.org> <9CB7ECE8-FF10-43BE-9EBD-16953BE3B193@xcllnt.net> In-Reply-To: <9CB7ECE8-FF10-43BE-9EBD-16953BE3B193@xcllnt.net> X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: marcel@FreeBSD.org, Eitan Adler , svn-src-all@FreeBSD.org, src-committers@FreeBSD.org, Bruce Evans , svn-src-head@FreeBSD.org Subject: Re: svn commit: r231814 - in head/sys: kern sys X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 09:44:32 -0000 Since this issue has generated a sudden interest, I would like to use this opportunity to point my older proposal as well: http://lists.freebsd.org/pipermail/freebsd-arch/2011-August/011405.html Essentially the algorithm is: 1. atomically (CAS) reserve a space in the message data buffer 2. output full message to the reserved space (no contention here) 3. atomically (CAS) append a pointer to the message in the message pointers buffer on 17/02/2012 06:49 Marcel Moolenaar said the following: > I think we should lift above the immediate problem and allow for > single- and multi-line messages that are atomically appended to > the message buffer. Console output and propagation of messages > outside of the kernel should all come out of the message buffer > and preserving the atomicity of the messages. > > The message buffer does not have to be a chunk of memory that > we circularly scribble to. It can be a per-cpu linked list of > messages even. > > The advantage of thinking along these lines is that: > 1. Console output can be made optional very easily, allowing > us to implement quiet boots without loosing the ability > to look at messages collected during boot. > 2. Atomicity allows us to parse the messages reliably, which > works very well in the embedded space where monitoring of > kernel messages is common. > 3. You can decouple writing into the message buffer from > extracting messages out of the message buffer, allowing > the low-level console to become just another channel to > send messages to, rather than be fundamental for printf. > 4. A linked list (for example) eliminates the problem of > scribbling over old messages and possibly leaving partial > output that gets misinterpreted. > 5. A per-cpu message buffer eliminates serialization to > guarantee atomcity and with timestamping can very easily > be turned into a sequential log. > 6. We haven't introduced complications (e.g. locking) to > solve these problems and that make using printf in low- > level code impossible. Thank trap handlers or interrupt > handlers. > > Just a thought that this may be a good time to think > bigger or broader and address more problems while we're > at it, > -- Andriy Gapon