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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20071006222825.GK22435@flower.upol.cz>
Date:	Sun, 7 Oct 2007 00:28:25 +0200
From:	Oleg Verych <olecom@...wer.upol.cz>
To:	Jan Engelhardt <jengelh@...putergmbh.de>
Cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Ingo Molnar <mingo@...e.hu>
Subject: Re: On text size and run time if config is "n", [PATCH 2/2] Colored kernel output (run3)

On Sat, Oct 06, 2007 at 11:27:54PM +0200, Jan Engelhardt wrote:
[]
> _call_console_drivers() skips the <N> 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 <N> 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 <N>, 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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/