Re: [evlog-dev] evlog module

Steve Woodruff wrote:
> 
> Is there any way that evlog could be modified
> such that it could be entirely contained as
> a loadable module?  ie: no kernel patch required?
> 

I will not say that it _cannot_ be implemented as a 
loadable module, but instead can give you some reasons
that in the beginning, this approach was shelved in 
favor of the current approach.  Remember, this assessment
was made in mid-2000 when we were all relatively new to
Linux.  Perhaps these issues could be addressed today.

1) In order to capture the very earliest events 
after bootup, before you are able to load modules, you
need event logging built-in to the kernel.  Similiarly,
we use a static buffer for events, so events before you 
are able to dynamically allocate memory can be captured.

2) If you define new functions for logging events, you
still need these defined in the kernel so that drivers,
etc. that use these functions don't get unresolved
symbols when they try to link.  
(Of course, inside these
logging functions you could simply return if the "evlog
module" was not loaded.)

Even if you only wanted to just forward printks() and turn
them into event records, you still need to patch printk to 
tap into the message stream.

> The reason I ask is that CGL vendors like RedHat
> and HP have no desire to support CGL installations
> in which the kernel is tainted or changed from
> the kernel they ship.  This is a big issue for
> us since RH flat out refuses to support any kernel
> that has evlog in it 

Do they give any reasons why ?  The only reason I've
heard is they are worried that if they include, say,
evlog vers. X, but evlog vers. Y gets accepted into
the upstream (2.5) kernel this creates awful compatibility
problems. I understand this completely, but I think we
have a migration story that _might_ address this issue.
I do know that UL 1.0 includes evlog-1.4.2, and they never
raised this issue. 


> Having evlog as a loadable module which wouldn't
> need a kernel patch would be a lifesaver.  Is there
> any technical way evlog could go in that direction?
> 

I'm not against saving your life :-), but I'm not sure we
can spend the time right now to investigate this.  Although,
it may serve _us_ well in the long-run too.  We'll have
to discuss it more.

Any other thoughts from you or the evlog team ?

Thanks,
Larry


-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com