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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1333846023.1834.21.camel@joe2Laptop>
Date:	Sat, 07 Apr 2012 17:47:03 -0700
From:	Joe Perches <joe@...ches.com>
To:	Kay Sievers <kay@...y.org>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, Greg Kroah-Hartmann <greg@...ah.com>
Subject: Re: [PATCH] printk: support structured and multi-facility log
 messages

On Fri, 2012-04-06 at 20:35 +0200, Kay Sievers wrote:
> On Thu, 2012-04-05 at 18:31 -0700, Linus Torvalds wrote:
> > 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.
> 
> Here is only the conversion of the byte- to the record-buffer split out
> of the big patch.
> 
> Unfortunately, it's still pretty big, and the patch not easy to read;
> the code itself looks better than the patch. At this moment I have no
> convincing idea how to split that into more pieces.

I'll spend some time on breaking up Kay's
patch in the next couple of weeks.

I'll try to get my printk restructuring patch
out by Monday.

I think Kay's still relatively large patch can
be broken into a sequence of:

1.  log_buf record oriented patch only
2.  S
 what I think is an
intelligible sequence of small concept pieces
and submit it end of April.  I'll be more or
less unavailable until then though.




--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ