From owner-freebsd-arch@FreeBSD.ORG Sun May 28 06:17:21 2006 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 22A4A16B3CE for ; Sun, 28 May 2006 06:13:26 +0000 (UTC) (envelope-from lyndon@orthanc.ca) Received: from orthanc.ca (orthanc.ca [209.89.70.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id B71FB43D46 for ; Sun, 28 May 2006 06:13:25 +0000 (GMT) (envelope-from lyndon@orthanc.ca) Received: from [192.168.15.2] (d154-5-28-131.bchsia.telus.net [154.5.28.131]) (authenticated bits=0) by orthanc.ca (8.13.4/8.13.4) with ESMTP id k4S6DL8T034237; Sun, 28 May 2006 00:13:21 -0600 (MDT) (envelope-from lyndon@orthanc.ca) In-Reply-To: <16029.1148764704@critter.freebsd.dk> References: <16029.1148764704@critter.freebsd.dk> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <67EC575F-CEE3-43DF-A811-18930687DABD@orthanc.ca> Content-Transfer-Encoding: 7bit From: Lyndon Nerenberg Date: Sat, 27 May 2006 23:12:29 -0700 To: Poul-Henning Kamp X-Mailer: Apple Mail (2.750) X-Spam-Status: No, score=1.2 required=5.0 tests=AWL,BAYES_00, RCVD_IN_NJABL_DUL,RCVD_IN_SORBS_DUL autolearn=no version=3.1.1 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on orthanc.ca Cc: arch@freebsd.org Subject: Re: A sort of plan for consoles in FreeBSD 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: Sun, 28 May 2006 06:17:25 -0000 Just as a neutral data point ... CTIX (Convergent Technologies SVRx from the mid 1980s) ran /dev/ console such that writes went into an in-kernel circular buffer. Reads from /dev/console would drain the contents of that buffer. I didn't like the read behaviour; it would have been more useful if reads didn't empty the buffer. But I did like how easy it was to examine the buffer with crash after a panic. While this isn't directly applicable to BSD, I do like the concept of having that kernel message log. It addresses the issues that others have raised about syslog not having time to commit to disk, or do a network write during kernel death. I would gladly pay for a meg or so of kernel memory to hold such a write buffer (size tunable by sysctl). --lyndon