Date: Tue, 14 Mar 95 10:52:02 MST From: terry@cs.weber.edu (Terry Lambert) To: joerg_wunsch@uriah.heep.sax.de Cc: freebsd-bugs@FreeBSD.org Subject: Re: 950210-SNAP Problems ... Message-ID: <9503141752.AA07865@cs.weber.edu> In-Reply-To: <199503140720.IAA01311@uriah.heep.sax.de> from "J Wunsch" at Mar 14, 95 08:20:47 am
next in thread | previous in thread | raw e-mail | index | archive | help
> 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9503141752.AA07865>