From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve Grubb Subject: Re: A question about auditd_reply_list and auditd_consumer_data in Audit.c and Auditd-event.c Date: Mon, 19 May 2008 13:27:42 -0400 Message-ID: <200805191327.43538.sgrubb@redhat.com> References: <003001c8b706$a5c2c130$548da70a@truly> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <003001c8b706$a5c2c130$548da70a@truly> 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: chuli Cc: 'Linux Audit' List-Id: linux-audit@redhat.com On Thursday 15 May 2008 11:40:55 pm chuli wrote: > I have read source code in Audit-1.6.5 about auditd part. I looked up into > functions equeue_event(),event_thread_main() in > Auditd-event.c,get_reply(),send_audit_event() and main function in > Auditd.c. I don't know why it must use a list (auditd_reply_list) here. As the code stands today, it does not need it. I keep the project's future development needs/goals in a TODO file at the top directory in the source tarball. I have a goal of making an internal queue between the listener and disk writing threads. What I wanted to do was get it working in audispd and then backport that same queue mechanism into auditd. But I wanted it to get tested out before pulling it into the more critical auditd code. I plan to add this internal queue in the 2.0 series which should start in the next month or two. -Steve