[lkml]   [1996]   [Jun]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Ideas for v2.1
> > > >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 _STRONGLY_ don't agree (but that is good isn't it? :-)
> Hey, me too! =:^)
> > printk _KNOWS_ what sequences it can handle, and can _easily_
> > be told to not log other sequences.
> >
> > Example: "Hello %E3[K4world%E3[K2\n" (note: bogus esc seqences)
> > %En could be defined as meaning an escape sequence of length n.
> Absolutely not. That's unnecessary.
> We can safely assume that all escape sequences used in the kernel messages
> will be standard ANSI X3.64 stuff. The most common, most useful X3.64
> escape sequences (if not all of them) begin with escape, and end with a
> character with bit 6 set. So a piece-of-cake little two- or three-state
> machine could easily pull escape sequences out before logging. Or we could
> do it at userlevel with something like awk (or sed, to appease Olaf Kirch
> =:^) )

Neat - i didn't know about this bit 6 thing.

> Anyway, doesn't %E conflict with a printf token?

Likely. I just "threw it out there" as an example.

Andrew E. Mileski My home page
Linux Plug-and-Play Project Leader. See URL

Red Hat Software sponsors these pages - I have no other affilitation
with Red Hat Software, and I have never used any of their products.

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