Kobject_Uevent and DBUS

[Ikke]

On Sun, 2005-01-09 at 21:30 +0100, Kay Sievers wrote:
> On Sun, 2005-01-09 at 21:10 +0100, Ikke wrote:
> > If I add a uevent into the kernel, that tells userspace process XYZ pid
> > 123 was killed because of an OOM, how does that fit into HAL?
> 
> Yes, that doesn't fit into the current HAL. But think of advanced error
> propagation from the kernel up to userspace, with all the fancy things
> like binary firmware dumps, unified error codes/messages, ...
> That all fit's nicely into HAL and messages like this may find it's
> place in HAL or some counterpart sometimes.
> 
> I'm just against broadcasting arbitrary kernel data without a real
> context to userspace applications.
Agree. I tought about it a little more, and now I'm asking my self how I
could ever be sos tupid to propose to put this into DBUS itself ;-)

> As an example you get all the hotplug events over netlink at the time
> sysfs is completely empty for that device and the event is more or less
> useless without the node name udev has created. So you just use HAL to
> get a sane event at the time the node is created and the device is ready
> to use.
> 
> > Similar things: a module was (un)loaded from/into the kernel
> 
> You get hotplug events for this.
> 
> >  user requested ACPI Suspend / swsusp (which can be usefull events for
> > userland/desktop applications: close connections nicely (IM, IRC,...)
> > and reconnect on resume),...
> 
> The power management stuff is on the way into HAL.
I do know this. But as far as I followed that discussion, it'd have the
same concept/structure as current HAL: list devices, and properties of
them (batteries, buttons, fans,... all things kernel's ACPI
implementation provides), but not things which are software/kernel and
low-level ACPI only (like, ACPY S3 requested, etc). That's not really a
"hardware" thing.
But this isnt a discussion for dbus@fgo, my apologies...
> 
> Kay

Ikke