Re: On text size and run time if config is "n", [PATCH 2/2] Colored kernel output (run3)

[Jan Engelhardt]

On Oct 7 2007 00:28, Oleg Verych wrote:
>
>I thought, i was talking about *write() functions, that got one
>additional unrelated, non config removable API change in face of
>`unsigned int loglevel'.

Documentation/stable_api_nonsense.txt ;-)

>Idea. Extend those macro defines before format string with one
>additional macro, that will be empty, if config is NO and having
>colour byte otherwise.
>
>In the *write() functions, have
>
> color = str[0];
> ++str;

This is just as "bad" as the loglevel parameter. Because you'd have
to parse str[0] in _every_ write() function. Furthermore, the string
that is being printed also goes to klogd/syslog, including the 
tag already. If you now add a color byte in the KERN_* macros, then
that color byte would also go to syslog. Not good.

>Sorry, i don't know much about stuff, you've presented:

(Paraphrased one paragraph above.)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: On text size and run time if config is "n", [PATCH 2/2] Colored kernel output (run3)

[Oleg Verych]

On Sat, Oct 06, 2007 at 11:27:54PM +0200, Jan Engelhardt wrote:
[]
> _call_console_drivers() skips the  substring and passes on the rest of the
> message:
> 
> if (msg_level < 0 && ((end - cur_index) > 2) &&
> LOG_BUF(cur_index + 0) == '<' &&
> LOG_BUF(cur_index + 1) >= '0' &&
> LOG_BUF(cur_index + 1) <= '7' &&
> LOG_BUF(cur_index + 2) == '>') {
> msg_level = LOG_BUF(cur_index + 1) - '0';
> cur_index += 3;
> start_print = cur_index;
> }
> 
> >I mean, *write() have nothing to do with loglevels. If they do
> >(suddenly), then why not to use a char in the *str to make it possible? I
> >might be wrong, but there are already macros before format strings in
> >printk().
> >
> >And this is not `loglevel' thing any more. It's attributes, which can be
> >used by many other drivers/file systems/schedulers/ what ever, if
> >developers, like Ingo, will extend printk() output to be more nice in
> >subsystems they develop.
> 
> If I interpret you correctly, you want me to remove cur_index+=3
> and instead reparse  in drivers/char/vt.c. But that's not good,
> because if you use serial, we won't go to vt.c, and in the end,
> 8250.c would also need to parse , which I think is just walking
> around the hill.

I thought, i was talking about *write() functions, that got one
additional unrelated, non config removable API change in face of
`unsigned int loglevel'.

Idea. Extend those macro defines before format string with one
additional macro, that will be empty, if config is NO and having
colour byte otherwise.

In the *write() functions, have

 color = str[0];
 ++str;

in case if config is YES. And nothing otherwise.


Sorry, i don't know much about stuff, you've presented:

> kernel/printk.c -> 8250.c -> grab_loglevel_from_string -> ignore it and print
> message
> kernel/printk.c -> vt.c -> grab_loglevel_from_string -> print color according
> to loglevel

so maybe i just am an ignorant. Anyway this:

> VS
> 
> kernel/printk.c -> pass loglevel directly to 8250.c -> ignore loglevel and
> print message
> kernel/printk.c -> pass loglevel directly to vt.c -> print color according to
> loglevel

have no compile or run time optimization possible.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/