From owner-freebsd-arch@FreeBSD.ORG Sun May 28 06:57:44 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 5FAF916BC6D for ; Sun, 28 May 2006 06:46:33 +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 CC3B843D4C for ; Sun, 28 May 2006 06:46:32 +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 k4S6kTti034382; Sun, 28 May 2006 00:46:29 -0600 (MDT) (envelope-from lyndon@orthanc.ca) In-Reply-To: <20060528062623.GO744@turion.vk2pj.dyndns.org> References: <16029.1148764704@critter.freebsd.dk> <67EC575F-CEE3-43DF-A811-18930687DABD@orthanc.ca> <20060528062623.GO744@turion.vk2pj.dyndns.org> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <10D0C601-EF31-40BA-9438-12F2C6D23A72@orthanc.ca> Content-Transfer-Encoding: 7bit From: Lyndon Nerenberg Date: Sat, 27 May 2006 23:45:36 -0700 To: Peter Jeremy X-Mailer: Apple Mail (2.750) X-Spam-Status: No, score=1.1 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:58:04 -0000 On May 27, 2006, at 11:26 PM, Peter Jeremy wrote: > FreeBSD has had a message buffer as long as I can remember. Look in > for the API and kern.msgbuf for the content. I can't > find any man pages on it. I remember looking at this before a couple of times, but it seemed (I'm a bit fuzzy on the details now -- it's been a while) that the interface wasn't stable (or even documented, as you mentioned). If a documented API was nailed down, that would be great. But I would really like to see the read semantics of /dev/console made as I described, so that multiple readers could watch what was going on (e.g. multiple procs filtering the output and acting accordingly). This makes it much easier to write system monitors (ala swatch, doing the equivalent of 'tail -f') without having to do all kinds of ioctl goo against special /dev files. Being able to adjust the buffer size at runtime (via sysctl) would be a bonus. For example, when we get load storms on our web servers, it would be very helpful to be able to crank up the size of the buffer and turn up logging to try to catch something in the debug stream to explain what's going on. But I wouldn't want to run with a (say) 200MB console buffer in normal production. Dynamic sizing is perhaps just wishful thinking though -- we can certainly live without it. --lyndon