Re: [patch] kernel events layer

[Tim Hockin]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/