From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve Grubb Subject: Re: Performance of libauparse Date: Wed, 1 Oct 2008 14:46:26 -0400 Message-ID: <200810011446.26752.sgrubb@redhat.com> References: <48E22AC8.8010906@redhat.com> <1222866927.28251.115.camel@localhost.localdomain> <48E3A08C.2030501@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <48E3A08C.2030501@redhat.com> Content-Disposition: inline List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: linux-audit@redhat.com List-Id: linux-audit@redhat.com On Wednesday 01 October 2008 12:08:44 Matthew Booth wrote: > > Close, but not quite. =A0I say we can't change the kernel without com= plete > > backwards compatibility. =A0Show me the right solution and we can get > > there, we just can't throw away what's already there. > > My other mail listed 6 ways in which audit *has already broken* > userspace through non-backwards compatibility. Are they verified broken or just that something changed? Backwards=20 compatibility was worked in wherever possible. >The situation is still very messy, and this will continue to happen beca= use >the protocol has evolved organically rather than through deliberate des= ign, >and was not designed for extensibility. There was a deliberate design. Compactness and extensibility are sometime= s at=20 odds, though. But this is straying way away from your original post about= =20 performance improvements - which I would find to be topic worth talking=20 about. I will not participate in any rehash of past discussions about par= sing=20 or representation of data. -Steve