RE: [evlog-dev] [PATCH] Resolve kernel addresse to symbols in for mat "[symbolname +offset/size]"

Hi Hien,

I agree that I haven't thought about any other implementations before I
wrote the patch. Yes, implementing the feature in evlogd is simple but it is
not a good way regarding the load and the purity of the raw data. But I
think if we want to enable the feature outside of evlogd, we'd better do it
in API level as well as utility evlview.

1. Event read
The evlview might not be the only way for people to get the symbols resolved
message. So supporting a set of APIs to convert kernel addresses to symbols
like,

int ksym_init(const char *);  /* initialize system map files */
char * posix_log_resolve_symbols(const char *);  /* read messages from a
kernel addresses buffer and return with a symbols resolved buffer */

may be a good supplement for posix_log_read(). So people can get the symbol
resolved messages if they want to. These APIs are also called by evlview to
make it support the address symbol resolving.

2. Event query
I'm not sure if this is really useful, but just in case, a person may query
a certain kernel symbol name (like [usb_register]) and want to be notified
in his program. We need do some additional work to support this kind of
queries. Does this sound reasonable? :)


For the remote logging scenario, I think there are two choices.

1. We need System.map for each remote host we want to resolve kernel
addresses to symbols.

Cons
----
1) We need a way to get the system map file, or we leave it to the user.
2) It is very difficult to get the frequently updated kernel modules symbols
of the source host.

2. Let evlogrmtd log raw data locally (optional) and send resolved data to
remote consolidator host. 

The cons are the same as the evlogd implementation, taxing evlogrmtd.

Do we have any other choices to do this?


Thanks,
-Zhu Yi

> From: Hien Q Nguyen [mailto:[email protected]]
> Sent: Saturday, January 11, 2003 2:51 AM
 
> Hi Yi,
> 
> Thanks for your patch, you have been a great contributor to 
> our project.
> 
> On our enhancement list, we have stated that this feature 
> (resolving kernel
> address) would be added to the evlogd daemon.  However, we do 
> have second
> thought now on where would we want to implement this (evlogd 
> or evlview).
> There are pros and cons in both implementations, let me try 
> to list some of
> them
> 
> evlogd implementation
> ---------------------
> Pros
> ----
> 1. Greatly help in the remote logging scenario, since the 
> consolidator does
> not need the system maps from the remote clients.
> 
> Cons
> ----
> 1. Taxing evlogd.
> 2. More of similar looks up in the future will tax evlogd even more.
> 3. Event data are modified before logged (if a wrong system map is
> provided, however you did cover it with the -2 option)
> 
> evlview implementation
> ----------------------
> Pros
> ----
> 1. Basically doing all the works offline (hmm, wrong choice of words).
> 2. Adding more of similar looks up in the future will not 
> impact overall
> system performance.
> 3. Event data are in it true form in the log, it is up to the 
> interpreter
> (elview in this case) to interpret it.
> 
> Cons
> ----
> 1. Need to provide a solution for remote log.
> 
> 
> I would like to start some discussion on this topic. Please 
> feel free to
> add your pros/cons on the list.
> 
> One could argue that why could klogd live with its implementation. My
> answer is because it has too (since syslog messages is a text 
> base log), if
> it has an option to resolve the kernel address offline I 
> think it probably
> would :-)
> 
> Best regards, Hien.
> 
> 
> Hien Nguyen
> [email protected]
> (503) 578-4347


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