On Tue, Aug 31, 2004 at 07:05:24PM -0700, Daniel Stekloff wrote:
> On Tue, 2004-08-31 at 14:42, Robert Love wrote:
> > Here is the Kernel Events Layer rewritten as more of an asynchronous
> > sysfs change notifier. The concept of object and payload have been
> > removed. Instead, events are modeled as signals emitting from kobjects.
> > It is pretty simple.
> >
> > The interface is now:
> >
> > int send_kevent(enum kevent type, struct kset *kset,
> > struct kobject *kobj, const char *signal)
> >
> > Say your processor (with kobject "kobj") is overheating. You might do
> >
> > send_kevent(KEVENT_POWER, NULL, kobj, "overheating");
> >
> > We could get rid of signal and just require passing a specific attribute
> > file in sysfs, which would presumably explain the reason for the event,
> > but I think having a single signal value is acceptable. The rest of the
> > payload has been ditched.
> >
> > The basic idea here is to represent to user-space events as changes to
> > sysfs. Media was changed? Then that block device in sysfs emits a
> > "media_change" event.
> >
> > This patch includes two example events: file system mount and unmount.
> >
> > Kay has some utilities and examples at
> > http://vrfy.org/projects/kevents/
> > and
> > http://vrfy.org/projects/kdbusd/
> >
> > The intention of this work is to hook the kernel into D-BUS, although
> > the implementation is agnostic and should work with any user-space
> > setup.
> >
> > Best,
> >
> > Robert Love
>
>
> Hi Robert,
>
> Are you limiting the kernel event mechanism a little too much by getting
> rid of the payload? Wouldn't it be useful to sometimes have data at
> event time?
The motivation for doing this, is the ambitioned idea, that _data_ should
only be exposed through sysfs values to userspace. This would make it
possible for userspace to scan any state at any time, regardless of a
received event. Which should make the whole setup more reliable, as
applications can just read in the state at startup. We do a similar job
with udevstart, as all lost hotplug events during the early boot are
recovered just by reading sysfs and synthesize these events for creating
device nodes.
The same applies to the way back to the kernel. We don't want to send
data over the netlink back to the kernel, we can write to sysfs.
Very "simple" data still can be specified by the signal string, just
like a "verb" that describes, what actually happened with the kobject.
In the mount case, we send a "mount/unmount" event for the physical
device, and userspace can read "/proc/mounts" for the data, as
applications do today by polling.
Another version to do this (similar to Robert's CPU overheating example
above), is to create a owner value in the blockdevice's kset and let the
device claiming code fill that value. Then the signal may just be a simple
"add/remove" event for the "owner" file at device claiming and release.
Yes, it may require, that some things in the kernel need to use kobjects
to represent it's state to userspace, but that is a nice side effect and
better than a complicated definition, what the event may carry ot of the
kernel with every specific event, I think.
If you can think of any case we can't expose enough data with this model
or we will not be able to use sysfs, let us know.
Thanks,
Kay
On Wed, 2004-09-01 at 03:07, Kay Sievers wrote:
[snip]
> The motivation for doing this, is the ambitioned idea, that _data_ should
> only be exposed through sysfs values to userspace. This would make it
> possible for userspace to scan any state at any time, regardless of a
> received event. Which should make the whole setup more reliable, as
> applications can just read in the state at startup. We do a similar job
> with udevstart, as all lost hotplug events during the early boot are
> recovered just by reading sysfs and synthesize these events for creating
> device nodes.
>
> The same applies to the way back to the kernel. We don't want to send
> data over the netlink back to the kernel, we can write to sysfs.
Ok.. so if I wanted to send an event (that included data at event time)
from a driver for a particular device, I would send the event with the
send_kevent() call and create and maintain an attribute for that
specific event. In order for an application to receive the data for the
event, the driver would need to store the data for that event somewhere
and keep it. Unless there's a write attribute to tell me it's been read,
I must maintain it or write over it if the same event occurs again.
Is this how it's supposed to work?
Even though 1) there won't be many events and 2) few events will include
data - don't you think this is a bit too much development overhead for
the driver?
If you had the payload with the event, you could fire and forget. It
would be fewer steps for the driver and require less management and
storage.
Thanks,
Dan
On Thu, 2004-09-02 at 13:45 -0700, Daniel Stekloff wrote:
> On Wed, 2004-09-01 at 03:07, Kay Sievers wrote:
> [snip]
> > The motivation for doing this, is the ambitioned idea, that _data_ should
> > only be exposed through sysfs values to userspace. This would make it
> > possible for userspace to scan any state at any time, regardless of a
> > received event. Which should make the whole setup more reliable, as
> > applications can just read in the state at startup. We do a similar job
> > with udevstart, as all lost hotplug events during the early boot are
> > recovered just by reading sysfs and synthesize these events for creating
> > device nodes.
> >
> > The same applies to the way back to the kernel. We don't want to send
> > data over the netlink back to the kernel, we can write to sysfs.
>
>
> Ok.. so if I wanted to send an event (that included data at event time)
> from a driver for a particular device, I would send the event with the
> send_kevent() call and create and maintain an attribute for that
> specific event. In order for an application to receive the data for the
> event, the driver would need to store the data for that event somewhere
> and keep it. Unless there's a write attribute to tell me it's been read,
> I must maintain it or write over it if the same event occurs again.
>
> Is this how it's supposed to work?
No, the current version(idea) is mainly a sysfs/kobject notification,
not a data channel, or something that requires a more complicated logic.
(but, yes, your example applies to simple event sequence numbers too. We
can't expose these kind of "snapshot data" by a sysfs value).
> Even though 1) there won't be many events and 2) few events will include
> data - don't you think this is a bit too much development overhead for
> the driver?
>
> If you had the payload with the event, you could fire and forget. It
> would be fewer steps for the driver and require less management and
> storage.
There will be only very few cases for that, but some drivers will want
to send these kind of information to userspace (even binary blobs).
Don't know if this kind of data dump should be part of kevent or better
handled by something driver specific. It gets even more complicated, if
the userspace listener must interpret all these different data formats.
Maybe we just need to rename "kevent" to "kobject_notify" to make the
focus more clear :)
Thanks,
Kay
On Thu, 2004-09-02 at 15:15, Kay Sievers wrote:
[snip]
> Maybe we just need to rename "kevent" to "kobject_notify" to make the
> focus more clear :)
Thanks, Kay, for answering my questions.
I'm wondering if you've narrowed the interface too much in respect to
possible events. I'm interested in error event notification. My goal is
to work on creating common, consistent, and meaningful error messages or
notifications that can be easily understood or used to trigger events.
Possible responses to error messages - in User Space - could be to spit
out a more detailed error message to the console that includes possible
causes, possible actions, and the erroring device information (gathered
from HAL and/or sysfs) or to automatically launch a diagnostic.
While I'm currently more interested in the actual error events, I
thought I could take advantage of the proposed kevent interface because
parsing /var/log/messages is cumbersome. But now I'm not so sure.
I was thinking the send_kevent form that included the payload could be
put into dev_err() macros, so we didn't have to add yet another
interface to drivers. We could just patch dev_err(). I even thought we
could add a dev_event() for using specific events.
Now I'm wondering if this interface would be useful for error events.
Most error events don't require data at event time, but there are some
that do.
If you curious about the error events, I've started a list of actionable
error events that includes the current message string, possible causes,
and possible actions (it's a work in progress):
http://linux-diag.sourceforge.net/first_failure/FirstFailure.html
Thanks,
Dan
On Fri, Sep 03, 2004 at 04:59:51PM -0700, Daniel Stekloff wrote:
> On Thu, 2004-09-02 at 15:15, Kay Sievers wrote:
> [snip]
> > Maybe we just need to rename "kevent" to "kobject_notify" to make the
> > focus more clear :)
>
>
> Thanks, Kay, for answering my questions.
>
> I'm wondering if you've narrowed the interface too much in respect to
> possible events. I'm interested in error event notification.
I don't think this "event notification" system should be used for error
event notification. For errors, you want to never drop them, or want to
rely on userspace reading the sysfs attribute file in time before it
changes again.
And as my previous message shows, I think we just evolved back to the
current hotplug interface, which really isn't a good one for errors :)
> If you curious about the error events, I've started a list of actionable
> error events that includes the current message string, possible causes,
> and possible actions (it's a work in progress):
>
> http://linux-diag.sourceforge.net/first_failure/FirstFailure.html
That's a great start. Hopefully it will help in figuring out what error
messages should be standardized on across drivers that belong to the
same class.
thanks,
greg k-h