From mboxrd@z Thu Jan 1 00:00:00 1970 From: Matthew Booth Subject: Re: get_field_str() and interpret_field() bug with multi-word fields Date: Tue, 12 Aug 2008 23:10:40 +0100 Message-ID: <48A20A60.8000605@redhat.com> References: <0E43BF2D7491F0468B56B1A5C493866B020DD0F1@SAT4MX07.RACKSPACE.CORP> <48A1D367.6090306@redhat.com> <200808121713.12919.sgrubb@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <200808121713.12919.sgrubb@redhat.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Steve Grubb Cc: William Kelly , linux-audit@redhat.com, Bret Piatt List-Id: linux-audit@redhat.com Steve Grubb wrote: > If somebody has a better idea/code in hand when we start the 2.0 code, I'd > like to consider it. The pre-requisites are it has to be backward compatible, > it has to handle unicode, it has to handle fields with odd characters. I have thought for some time now that the kernel would do better to produce binary records. This would have many advantages, including: * Very simple parsing * Much faster to parse * Faster to produce * Much easier to specify The production of text would then be the problem of the audit daemon. If the current text based nightmare were frozen, they could even live side-by-side. Matt -- Matthew Booth, RHCA, RHCSS Red Hat, Global Professional Services M: +44 (0)7977 267231 GPG ID: D33C3490 GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490