From owner-freebsd-arch@FreeBSD.ORG Fri Sep 2 09:40:30 2005 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 650AC16A41F for ; Fri, 2 Sep 2005 09:40:30 +0000 (GMT) (envelope-from trhodes@FreeBSD.org) Received: from pittgoth.com (14.zlnp1.xdsl.nauticom.net [209.195.149.111]) by mx1.FreeBSD.org (Postfix) with ESMTP id EAEFD43D45 for ; Fri, 2 Sep 2005 09:40:29 +0000 (GMT) (envelope-from trhodes@FreeBSD.org) Received: from localhost (tradenet-it.gw.ai.net [205.134.160.6] (may be forged)) (authenticated bits=0) by pittgoth.com (8.13.3/8.13.3) with ESMTP id j829eR4E081914 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 2 Sep 2005 05:40:28 -0400 (EDT) (envelope-from trhodes@FreeBSD.org) Date: Fri, 2 Sep 2005 05:39:27 -0400 From: Tom Rhodes To: Poul-Henning Kamp Message-ID: <20050902053927.3656b245@localhost> In-Reply-To: <34182.1125646759@phk.freebsd.dk> References: <34182.1125646759@phk.freebsd.dk> X-Mailer: Sylpheed-Claws 1.9.13 (GTK+ 2.6.8; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: arch@FreeBSD.org Subject: Re: Consoles, past and future. 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: Fri, 02 Sep 2005 09:40:30 -0000 On Fri, 02 Sep 2005 09:39:19 +0200 Poul-Henning Kamp wrote: [SNIP] > Nobody mandates that 2 & 3 has to happen on "/dev/console", /sbin/init > could open any device it prefer for this, so if the device drivers > export a proposed device name along with their console functions, > /sbin/init could pick this up with a sysctl and proceed from there. > The loader could present a hint to override this. > > That leaves us with 4 and 5, which we can't do much about because > short-sighted UNIX standards which goldpated the past rather than > steer the future and therefore mandate that /dev/console must be a > tty(4) device. > > But we can implement /dev/console as a pseudo device driver without > breaking anything. > > Most people these days view this part of the console functionality > through syslog or xconsole(-like) programs anyway which uses various > ioctls to get their bit of the cake. > > In order to stay compatible with old stuff, we could use a null-modem > backside device so that people could say "tip console" and interact > with dump(8) that way. (Keeping a buffer of the most recent 2K output > and replaying that on open would probably be a good idea). > > The driver would also have the task of directing the output to > /dev/console to syslogd for permanent recording. > > Thanks for listening. > You're welcome. :) My question is, and I know this hasn't been tested so be my guest and theorize a bit. Are there any performance gains or losses as a result of taking this route? -- Tom Rhodes