Re: [patch] kernel events layer, updated

[Deepak Saxena]

On Jul 23 2004, at 23:11, Robert Love was caught saying:
> @@ -59,9 +60,15 @@
>  	if (l & 0x1) {
>  		printk(KERN_EMERG "CPU%d: Temperature above threshold\n", cpu);
>  		printk(KERN_EMERG "CPU%d: Running in modulated clock mode\n",
> -				cpu);
> +			cpu);
> +		send_kevent(KMSG_POWER,
> +			"/org/kernel/devices/system/cpu/temperature", "high",
> +			"Cpu: %d\n", cpu);
>  	} else {
>  		printk(KERN_INFO "CPU%d: Temperature/speed normal\n", cpu);
> +		send_kevent(KMSG_POWER,
> +			"/org/kernel/devices/system/cpu/temperature", "normal",
> +			"Cpu: %d\n", cpu);

Robert,

What is the the specified naming scheme for objects and in the case of 
devices, why not use the sysfs path as part of the object path? For example:

	"/org/kernel/system/cpu/cpu0"

Since we have unique paths for devices in syfs, this would remove the need 
of having the anxiliary "CPU: %d" as it is embedded in the object name. 

Also, why the "/org/kernel"? Since all message from the kernel
can only come from the kernel, why do we need this as part of the object
name?  Looking at the D-BUS spec, it looks like the "org.foo" is part of the 
D-BUS/HAL/freedesktop naming scheme, but this should not be pushed into
the kernel IMHO. As you yourself mentioned in your talk today, D-BUS
is just one daemon that could use the kevents interface, so I don't
think we want to push it's naming scheme into the kernel messages.
The kernel should use an object name that is unique in the context 
of the kernel (hence my suggestion to use sysfs path, but perhaps there
is something else?) and D-BUS should generate the appropriate object 
name that it expects.  The kernel is never going to send messages for 
objects in org.freedesktop or anything !org.kernel, so we are just 
stuffing extra bytes in the message that are very specific to a given 
userland implementation.

You also mentioned some interesting usage examples of HAL/D-BUS/kevents 
in your talk. Any possibility of getting a patch with the kernel specific
changes?  I ask b/c I would like to see how you imagine this being used in 
the context of things like device add/remove and other things device driver 
writers would be dealing with it.

Tnx,
~Deepak

-- 
Deepak Saxena - dsaxena at plexity dot net - http://www.plexity.net/

"Unlike me, many of you have accepted the situation of your imprisonment and
 will die here like rotten cabbages." - Number 6
-
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/