[lkml]   [2004]   [Jul]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [patch] kernel events layer
On Fri, Jul 23, 2004 at 01:41:57PM -0400, Robert Love wrote:
> OK, Kernel Summit and my OLS talk are over, so here are the goods.

It's good to see something concrete in this vein. Is this interface going
to be intended for things like error states? The first thing that jumps
to mind is all the evlog stuff that was argued about last year.

Is this interface intended to be used in the name of driver "hardening"
and fault handling?

> + send_kmessage(KMSG_POWER,
> + "/org/kernel/devices/system/cpu/temperature", "high",
> + "Cpu: %d\n", cpu);

I have to ask why the path needs to include /org ? It seems pretty much
like useless stuff. In fact, why does it need to specify /org/kernel?
Userspace can safely assume that anything that comes out of the netlink
socket is from the kernel, no?

If userspace is going to use this "object" path as a globalish identifier,
it can prepend hatever it needs. Really, it should prepend some sort of
network id, if this stuff is ever going to find a network, so eliminating
the /org/kernel might just be precedent.

At worst case, why type it in every call to send_kmessage? If they ALL
start with /org/kernel, just add that inside the send_kmessage() guts.

Further, if you want to eliminate stupid typo errors, these paths cn be
further macro-ized.

send_kmessage(KMSG_POWER, KMSUBSYS_CPU, "temperature", "high",
"Cpu: %d", cpu);

KMSUBSYS_CPU can be recognized and expanded to "/devices/system/cpu".
That way, no one ever misspels it, leaving you stuck with it. Also note
that requiring the caller to pass a '\n' seems pretty dumb.

Just my initial thoughts. I need to read the paper, still.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 14:04    [W:0.091 / U:0.828 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site