lkml.org 
[lkml]   [1996]   [Jun]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: Ideas for v2.1
From
Date
In article <199606131535.LAA01225@nic.ott.hookup.net> you write:
>> > driver in full working order. So can't we just replace "Ok.\n" with
>> > "\r\e[K", which will wipe the message off the screen *if* the test
>> > is successful.
>>
>> But these escape sequences would also go to the log files, which
>> is probably not good...
>
>It would a simple matter to _NOT_ log escape sequences, since
>printk would already have to detect them in the first place.
>The escape code just shouldn't be put in the buffer.

No, it would probably be quite tricky. I'm sure someone will jump on
me if I'm wrong, but as I see it the escape sequence is generated by
the compiler as a string literal and passed in the original call to
printk(). printk() sorts out logging and buffering as necessary, and
by default (with no klogd) will output the string verbatim to the
console device. The console device then interprets any escape
sequences as necessary. You really don't want to have to *interpret*
the sequences anywhere other than in the console code, and this is
basically what you have to do to figure out how many characters after
the initial escape code \033 need to be ignored.

To strip it out you have to do one of the following:

Write an intelligent log viewer that correctly detects and removes VT
escape sequences. Tricky.

Write a printk() that understands VT escape sequences at least as well
as the console driver, so can remove them for the logs. Bletch.
Or genericize the routine for detecting and sizing escape sequences.
Have you *read* the console code recently?

View logs through `| tr -d '\033'` and settle for some garbage getting
through (like '[0p's or whatever all over the place). Hack.

Split all kernel printk()s into 2 parts: a screen-viewable string
possible with escape sequences, and a sanitised version for the logs.
Double bletch.

Write a printk() with extra tags ("<GREEN>", "<ERASELINE>" etc...)
which are translated into the correct sequence for the screen
version, but removed for the logged version. Could work well.

Not care about escape sequences getting into your logs. Easy.

Colourized boot messages would certainly look pretty, and make
searching for the driver detect line that's gone missing easier. That
said, I accidentally deleted color-ls some time ago (which I used to
swear by) and haven't looked back. Some purists might consider
colourized boot messages in the same light that die-hard PDP11 hackers
regarded the new-fangled hexadecimal keypad on console emulators.
Octal flip-switches were far more *fun* ;) Take your pick.

John
--
i built it up now i take it apart climbed up real high now fall down real far
no need for me to stay the last thing left i just threw it away
i put my faith in god and my trust in you
now there's nothing more fucked up i could do
<p><a href="http://callisto.girton.cam.ac.uk/users/js10039/">Me.</a>


\
 
 \ /
  Last update: 2005-03-22 13:37    [W:0.102 / U:1.068 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site