From owner-svn-src-all@FreeBSD.ORG Fri Feb 17 04:49:27 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 2FC8D1065673; Fri, 17 Feb 2012 04:49:27 +0000 (UTC) (envelope-from marcel@xcllnt.net) Received: from mail.xcllnt.net (mail.xcllnt.net [70.36.220.4]) by mx1.freebsd.org (Postfix) with ESMTP id E14768FC0A; Fri, 17 Feb 2012 04:49:26 +0000 (UTC) Received: from [172.23.7.53] (natint3.juniper.net [66.129.224.36]) (authenticated bits=0) by mail.xcllnt.net (8.14.5/8.14.5) with ESMTP id q1H4n9OJ099284 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 16 Feb 2012 20:49:17 -0800 (PST) (envelope-from marcel@xcllnt.net) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Marcel Moolenaar In-Reply-To: <4F3D9D03.6020507@FreeBSD.org> Date: Thu, 16 Feb 2012 20:49:05 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <9CB7ECE8-FF10-43BE-9EBD-16953BE3B193@xcllnt.net> 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> To: Andriy Gapon X-Mailer: Apple Mail (2.1257) Cc: marcel@freebsd.org, Eitan Adler , svn-src-all@freebsd.org, "Kenneth D. Merry" , src-committers@freebsd.org, Bruce Evans , svn-src-head@freebsd.org, Julian Elischer 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 04:49:27 -0000 On Feb 16, 2012, at 4:19 PM, Andriy Gapon wrote: > on 17/02/2012 02:08 Kenneth D. Merry said the following: > [snip] >>>> On Thu, Feb 16, 2012 at 11:13:09 +0200, Andriy Gapon wrote: > [snip] >>>>> For me personally the immediate benefits in the common situations=20= >>>>> outweighed the >>>>> problems in the edge cases, although I still believe that we can = get the=20 >>>>> former >>>>> without sacrifices in the latter. > [snip] >> It sounds fine, but I don't have sufficient time to spend on this = right >> now. So I can either back out the changes I mentioned above = (assuming we >> get agreement from avg), or leave things as is. >=20 > I stick to what I wrote above and so chose the status quo. > The backout would make sense if it is immediately followed by commit = of a better > solution. Unfortunately, a lack of time here too. 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, --=20 Marcel Moolenaar marcel@xcllnt.net