Messages in this thread | | | Date | Fri, 23 Jul 2004 11:25:54 -0700 | From | Tim Hockin <> | Subject | Re: [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.
Tim - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |