linux-kernel - Re: [PATCH] printk: support structured and multi-facility log messages

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: <CA+55aFyE41U9OPr7mrAA2ZJKuQ2jvH-KmusUNyfYbH8tOm6yiQ@mail.gmail.com>
Date:	Thu, 5 Apr 2012 18:31:04 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Joe Perches <joe@...ches.com>
Cc:	Kay Sievers <kay@...y.org>, linux-kernel@...r.kernel.org,
	Greg Kroah-Hartmann <greg@...ah.com>
Subject: Re: [PATCH] printk: support structured and multi-facility log messages

On Thu, Apr 5, 2012 at 6:12 PM, Joe Perches <joe@...ches.com> wrote:
>
> I still think this should be 3 patches not 1.

I do agree that that would be lovely. That patch is really hard to
read, and it would be helpful if some of it was split up a bit. For
example, separating out the "move log buffer to be packetized"
(without actually doing the new things) from for the "introduce new
interfaces" would be quite nice.

In fact, I think I could merge something that does the packetization
early, if it is fairly obvious that it doesn't do anything else. Just
making the dmesg ASCII timestamp be something that is a "read buffer"
time thing rather than "generate printk" time thing would be nice, and
I think the sequence numbers can be useful even with all the old
interfaces.

So if somebody wants to help with things like that, and try to turn
this into a more gradual thing, I think we could merge at least some
initial parts of this patch even for 3.4.

Anybody interested?

                  Linus

PS looking some more at the patch, it has some more obvious insanities
in it. Doing "SUBSYSTEM=(NULL subsystem)" is clearly just insane. If
you don't have a subsystem, you shouldn't have that key/value pair -
saying you have a NULL subsystem is just crazy. Details like this
would possibly stand out a bit more if it wasn't one big patch.
--
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/