RE: [evlog-dev] remote logging with evlogrmtd

Get it! Thank you for your quick reply.



> > Does the host node need to know the architecture of the remote
> consolidator node...?
> No.
> 
> > Otherwise can we say that the binary file 
> /var/evlog/eventlog will be the
> same format among all the architectures...?
> That would sure make things easier, and we (and the POSIX 
> working group)
> certainly discussed the possibility of an architecture-independent log
> format.  The problem we can't get past is that the 
> optional-data portion of
> an event record is, by definition, opaque.  In a 
> BINARY-format record, you
> log the data (which could be any stream of bytes), but not its
> interpretation.
> 
> In our prototype implementation of a libevl + evlview that 
> handles foreign
> event logs, the interpretation of a BINARY record is specified by a
> formatting template -- just as with local event logs.  In case you're
> interested, here's the strategy behind this implementation.   
> (This was
> written before we implemented it; hence the use of future tense.)
> -----
> "In our current implementation of event logging, relatively 
> few functions
> need to “know” the format of the log and the individual 
> records.  The idea
> is to make these functions smart enough to recognize event 
> logs and records
> from “foreign” architectures, and handle them appropriately.  These
> functions are:
> ·     posix_log_open()
> ·     posix_log_read()
> ·     posix_log_seek()
> ·     evl_populatetemplate()
> ·     posix_log_write()
> 
>  The posix_log_write() function can be ignored because it is 
> not used to
> read the log.
> 
> Assume that the log header will be modified to contain some indication
> [encoded in the log header's magic number - Jim] of the 
> architecture on
> which the log was written.  The posix_log_open() function 
> will record this
> architecture ID in the log descriptor it returns.
> 
> For a foreign record, posix_log_read() will translate the 
> posix_log_entry
> struct in the log into the native format.  It will provide an 
> untranslated
> copy of the variable portion of the record.
> 
> Similarly, posix_log_seek() will use the architecture ID to correctly
> interpret each record header and the record size at the end 
> of each record.
> 
> evl_populatetemplate() will consult the architecture ID when 
> populating the
> template with values from the variable portion of the record."
> -----
> We figure that the only thing that will be different when we support
> "mixed" event logs is that each record's architecture ID will 
> be encoded in
> that record's magic number.
> 
> Of course, display of foreign BINARY records presupposes that 
> if host A
> sends a BINARY record to consolidator host B, B will have 
> access to A's
> templates when the record is displayed on B.  This works if A 
> and B both
> use the same set of templates, or if A's templates are made 
> available on B
> (perhaps in /var/evlog/templates/A/).  But this is an issue 
> even for hosts
> with the same architecture.
> 
> Jim Keniston
> IBM Linux Technology Center - RAS


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