From owner-freebsd-bugs Tue Mar 14 13:33:36 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id NAA04242 for bugs-outgoing; Tue, 14 Mar 1995 13:33:36 -0800 Received: from cs.weber.edu (cs.weber.edu [137.190.16.16]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id NAA04228 for ; Tue, 14 Mar 1995 13:33:34 -0800 Received: by cs.weber.edu (4.1/SMI-4.1.1) id AA07865; Tue, 14 Mar 95 10:52:03 MST From: terry@cs.weber.edu (Terry Lambert) Message-Id: <9503141752.AA07865@cs.weber.edu> Subject: Re: 950210-SNAP Problems ... To: joerg_wunsch@uriah.heep.sax.de Date: Tue, 14 Mar 95 10:52:02 MST Cc: freebsd-bugs@FreeBSD.org In-Reply-To: <199503140720.IAA01311@uriah.heep.sax.de> from "J Wunsch" at Mar 14, 95 08:20:47 am X-Mailer: ELM [version 2.4dev PL52] Sender: bugs-owner@FreeBSD.org Precedence: bulk > As Terry Lambert wrote: > > > > > > You can't have too many static strings in the kernel! > > > > > > So perhaps it should be made an LKM? :--) > > > > As in "there is no such thing as too many static strings in the kernel" > > > > ...or was that "too many static strings in the kernel would be bad". > > I rather thought of an LKM to interpret the ASC's. Syslogd could > load it... :-) At least, the strings are no longer _static_ then. Actually... A console message interpreter program would be a nice thing, as would a rolling log in the kernel as a /dev (UNIX uses /dev/osm for "OS Messages"). The intent of the program would be to output console messages to the console, with no other connection to the console. That is, it would live on the "master" end of a 2 headed device, with the slave end being the currently active console message destination and the master end bing /dev/console. Actually, this distinction has been a long time coming for the console device. Real pain for X Consoles. The main boot and other messages would go to /dev/console (and thus to the target for /dev/console's hidden slave). You can't really do anything about those. But the translation of the rolling log ought to be subject to internationalization and catalog entry. The main sticky point to take care of is allowing multiple readers of /dev/osm to deal with it their own way and to roll the log on message boundries. ,-------- kernel messages --------. | | | ,-> translator -. | | | | | | | | | v | v v /dev/osm >>>>>> /dev/osm /dev/console >> ? varies ? (source) (sink) (source) (sink) The main problem now goes back to another issue that was recently discussed, which is serial I/O and the concept of canonical vs. signal processing on devices. Really, the signal processing want to be tied to the device references and the console output wants to have a permanent location (the "real" console) and a temporarily reassigned location (the "current console message destination") which could be a pty for an X terminal. This implies a logical seperation of signal processing and cannonical processing, which is part of what is necessary to reduce the serial driver porting overhead (by increasing the amount of shared code) anyway. Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.