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.
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.
On Tue, 2004-08-31 at 15:00 -0700, Andrew Morton wrote: > Why not share the implementation here?
Because we will probably want to export do_send_kevent(), with a different name, if this thing starts getting used, because there are places where the kobj path is already computed and although inexpensive it does cost a few cycles to go kobject -> path as a string.
On Tue, 2004-08-31 at 14:58 -0700, Chris Wedgwood wrote: > I *still* thinking putting all the possible messages into something > like include/linux/kevent_msg.h is a good idea to prevent people > creating all sorts of stupid ad-hoc messages over time that userspace > will ineviitably not be able to track....
I still agree, but since that does not change the API (I'd still want the signal to be a string) that bit can come later when there are real users. Or I will take a patch now. ;-)
Since we ditched the payload, the only thing left is the signal, which is going to be "changed" half the time anyhow.
> On Tue, 2004-08-31 at 15:00 -0700, Andrew Morton wrote:
> > Why not share the implementation here?
> Because we will probably want to export do_send_kevent(), with a > different name, if this thing starts getting used, because there are > places where the kobj path is already computed and although inexpensive > it does cost a few cycles to go kobject -> path as a string.
That's unrelated. I meant:
static int __send_kevent(enum kevent type, struct kset *kset, struct kobject *kobj, const char *signal, int gfp_flags) { const char *path; int ret;
path = kobject_get_path(kset, kobj, gfp_flags); if (!path) return -ENOMEM;
ret = do_send_kevent(type, gfp_flags, path, signal); kfree(path);
EXPORT_SYMBOL_GPL(send_kevent_atomic); - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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.
> 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.
> 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?
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.
> > 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.
> > 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.
On Tue, Aug 31, 2004 at 06:05:24PM -0400, Robert Love wrote: > +int send_kevent(enum kevent type, struct kset *kset, > + struct kobject *kobj, const char *signal);
Why is the kset needed? We can determine that from the kobject.
How about changing this to: int send_kevent(struct kobject *kobj, struct attribute *attr); which just tells userspace that a specific attribute needs to be read, as something "important" has changed.
Will passing the attribute name be able to successfully handle the "enum kevent" and "signal" combinations?
On Thu, 2004-09-02 at 01:34, Greg KH wrote: > On Tue, Aug 31, 2004 at 06:05:24PM -0400, Robert Love wrote: > > +int send_kevent(enum kevent type, struct kset *kset, > > + struct kobject *kobj, const char *signal);
> Why is the kset needed? We can determine that from the kobject.
> How about changing this to: > int send_kevent(struct kobject *kobj, struct attribute *attr); > which just tells userspace that a specific attribute needs to be read, > as something "important" has changed.
Do all events require an attribute? What about the "overheating" example? Would you need an attribute or would getting a "signal" for a specific kobj be enough?
Binding an attribute to an event would at least tell you the name of the attribute to check. Otherwise, how does an app know the name of the attribute that changed? Or am I missing something?
Thanks,
Dan
> Will passing the attribute name be able to successfully handle the > "enum kevent" and "signal" combinations?
On Thu, Sep 02, 2004 at 10:34:08AM +0200, Greg KH wrote: > On Tue, Aug 31, 2004 at 06:05:24PM -0400, Robert Love wrote: > > +int send_kevent(enum kevent type, struct kset *kset, > > + struct kobject *kobj, const char *signal);
> Why is the kset needed? We can determine that from the kobject.
I expect it's because: fill_kobj_path(struct kset *kset, struct kobject *kobj, char *path, int length) get_kobj_path_length(struct kset *kset, struct kobject *kobj)
and therefore the exported: kobject_get_path(struct kset *kset, struct kobject *kobj, int gfp_mask)
are all passing the kset. If they all are not needed, they can go too?
> How about changing this to: > int send_kevent(struct kobject *kobj, struct attribute *attr); > which just tells userspace that a specific attribute needs to be read, > as something "important" has changed.
Hmm, in most cases this will work. But in mandates the creation of an attribute instead of the lazy signal string. Yes, it would be nicer in the long run and closer to the idea, that the whole event data should be available through sysfs, but it may be hard to reach this in some subsystems.
> Will passing the attribute name be able to successfully handle the > "enum kevent" and "signal" combinations?
What should we do in the hotplug case? We may send a NULL attr for the kset creation. But how can we distinguish between "add" and "remove"? Just by looking if we find the sysfs dir? I'm not sure in this case.
On Thu, Sep 02, 2004 at 05:02:46AM -0700, Daniel Stekloff wrote: > On Thu, 2004-09-02 at 01:34, Greg KH wrote: > > On Tue, Aug 31, 2004 at 06:05:24PM -0400, Robert Love wrote: > > > +int send_kevent(enum kevent type, struct kset *kset, > > > + struct kobject *kobj, const char *signal);
> > Why is the kset needed? We can determine that from the kobject.
> > How about changing this to: > > int send_kevent(struct kobject *kobj, struct attribute *attr); > > which just tells userspace that a specific attribute needs to be read, > > as something "important" has changed.
> Do all events require an attribute? What about the "overheating" > example? Would you need an attribute or would getting a "signal" for a > specific kobj be enough?
Hmm, both can be the case at the moment. We need to decide, if we want to mandate the use of a sysfs attribute instead of the string value as the signal.
> Binding an attribute to an event would at least tell you the name of the > attribute to check. Otherwise, how does an app know the name of the > attribute that changed? Or am I missing something?
That's a valid point, right. If we don't use "verbs" as the signal string, and know what we can expect from that particular kind of event, we don't know which attribute has changed.
The remaining questions are:
o Do we want the multicast - "channels" for the events? It may be nice, to have it, if a application only interested in e.g. hotplug events, can get only the interesting events?
o What kind of signal do we need? A lazy string, a well defined set like ADD/REMOVE/CHANGE? Or can we get rid of the whole signal? But how can we distinguish between add and remove? Watching if the sysfs file comes or goes is not a option, I think.
On Thu, 2004-09-02 at 10:34 +0200, Greg KH wrote: > Why is the kset needed? We can determine that from the kobject.
> How about changing this to: > int send_kevent(struct kobject *kobj, struct attribute *attr); > which just tells userspace that a specific attribute needs to be read, > as something "important" has changed.
> Will passing the attribute name be able to successfully handle the > "enum kevent" and "signal" combinations?
We can drop the kset if you say we never need it. Why do all the kobj get_path functions take a kset then? That is what confused me.
We can also drop the "enum kevent" if we decide we don't want to take advantage of the multicasting of the netlink socket. The enum defines what multicast group the netlink message is sent out in. I actually have been talking to Kay about ditching it, and we are trying to figure out if we ever _need_ it.
So that is 2 for 2. But ...
I don't dig replacing the signal string with an attribute. I think it will really limit what we can do - having the signal as a verb describing the event is really important. We might also not always have an attribute. Kay's points are all valid.
So what if we had
int send_kevent(struct kobject *kobj, const char *signal);
Which was a way of notifying user-space of a change of "signal" on the object "kobj" in sysfs.
If we ever wanted to send an attribute, we can do something like
const char *signal;
signal = attribute_to_string(attribute); send_kevent(kobj, signal); kfree(signal);
On Thu, 2004-09-02 at 15:26 +0200, Kay Sievers wrote: > o What kind of signal do we need? A lazy string, a well defined set like > ADD/REMOVE/CHANGE? > Or can we get rid of the whole signal? But how can we distinguish between > add and remove? Watching if the sysfs file comes or goes is not a option, > I think.
I think (from our off-list discussions) that we really need the signal. Agreed?
I do think that defining the signal to specific values makes sense, e.g. KEVENT_ADD, KEVENT_REMOVE, KEVENT_MOUNTED, etc. We could also send the attribute as a string.
To get around the hotplug issue that would occur without 'enum kevent', as we discussed, we could have a "hotplug_added" signal or whatever. Nothing wrong with that.
On Thu, 2004-09-02 at 09:25, Robert Love wrote: > On Thu, 2004-09-02 at 10:34 +0200, Greg KH wrote:
> > Why is the kset needed? We can determine that from the kobject.
> > How about changing this to: > > int send_kevent(struct kobject *kobj, struct attribute *attr); > > which just tells userspace that a specific attribute needs to be read, > > as something "important" has changed.
> > Will passing the attribute name be able to successfully handle the > > "enum kevent" and "signal" combinations?
> We can drop the kset if you say we never need it. Why do all the kobj > get_path functions take a kset then? That is what confused me.
> We can also drop the "enum kevent" if we decide we don't want to take > advantage of the multicasting of the netlink socket. The enum defines > what multicast group the netlink message is sent out in. I actually > have been talking to Kay about ditching it, and we are trying to figure > out if we ever _need_ it.
The only problem I see is making an app sift through all of the events to get to a specific type of event. They'd have to parse and match the signal, that could be costly.
Will there be small single purpose applications listening on the netlink socket or off dbus for specific signals? Or do you see this mainly handled by a single kevent daemon?
> I don't dig replacing the signal string with an attribute. I think it > will really limit what we can do - having the signal as a verb > describing the event is really important. We might also not always have > an attribute. Kay's points are all valid.
> So what if we had
> int send_kevent(struct kobject *kobj, const char *signal);
> Which was a way of notifying user-space of a change of "signal" on the > object "kobj" in sysfs.
> If we ever wanted to send an attribute, we can do something like
> const char *signal;
> signal = attribute_to_string(attribute); > send_kevent(kobj, signal); > kfree(signal);
> Dig that?
I thought you wanted to standardize the signals? Would you have a delimiter in your signal to have a standard prefix to use to identify the string in User Space?
Why not add the attribute name to the path you get from the kobj?
On Thu, 2004-09-02 at 11:35 -0700, Daniel Stekloff wrote: > The only problem I see is making an app sift through all of the events > to get to a specific type of event. They'd have to parse and match the > signal, that could be costly.
I'd hope that they were not that many events that it would ever be costly.
But this should be mitigated by your event aggregator in user-space, whether that is D-BUS or whatever else. If it is D-BUS, you could then subscribe via D-BUS only to the events you care about.
> Will there be small single purpose applications listening on the netlink > socket or off dbus for specific signals? Or do you see this mainly > handled by a single kevent daemon?
Whatever you want to do.
I think they way we would set up our Linux desktop product would have D- BUS listening on the kevent socket and propagating the events up the stack (or have a separate daemon listen and funnel the events to D-BUS. whatever).
Then applications up the stack would respond to and handle the D-BUS signals.
> 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.
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 :)
> 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):
Sorry, I'm at a conference, so email access is flaky at times...
On Thu, Sep 02, 2004 at 12:25:21PM -0400, Robert Love wrote: > On Thu, 2004-09-02 at 10:34 +0200, Greg KH wrote:
> > Why is the kset needed? We can determine that from the kobject.
> > How about changing this to: > > int send_kevent(struct kobject *kobj, struct attribute *attr); > > which just tells userspace that a specific attribute needs to be read, > > as something "important" has changed.
> > Will passing the attribute name be able to successfully handle the > > "enum kevent" and "signal" combinations?
> We can drop the kset if you say we never need it. Why do all the kobj > get_path functions take a kset then? That is what confused me.
Look at kobject_hotplug. We can determine the kset assigned to a kobject with the logic in that function. Then we use the kset to get the path and other good stuff that the hotplug call needs.
> We can also drop the "enum kevent" if we decide we don't want to take > advantage of the multicasting of the netlink socket. The enum defines > what multicast group the netlink message is sent out in. I actually > have been talking to Kay about ditching it, and we are trying to figure > out if we ever _need_ it.
Sounds fine to me.
> So that is 2 for 2. But ...
> I don't dig replacing the signal string with an attribute. I think it > will really limit what we can do - having the signal as a verb > describing the event is really important. We might also not always have > an attribute. Kay's points are all valid.
> So what if we had
> int send_kevent(struct kobject *kobj, const char *signal);
> Which was a way of notifying user-space of a change of "signal" on the > object "kobj" in sysfs.
Ok, I'll accept that, and I like it, it's simple, and yet powerful for pretty much everything we'll need in the future.
In fact, I like that type of function so much, I wrote it a few years ago: void kobject_hotplug(const char *action, struct kobject *kobj)
You fell right into my trap :)
So, we're back to the original issue. Why is this kernel event system different from the hotplug system? I would argue there isn't one, becides the transport, as you seem to want everything that we currently provide in the current kobject_hotplug() call.
But transports are important, I agree.
How about you just add the ability to send hotplug calls across netlink? Make it so the kobject_hotplug() function does both the exec() call, and a netlink call (based on a config option for those people who like to configure such stuff.)
That way, programs who want to listen to netlink messages to get hotplug events do so, and so does programs who want to do the /etc/hotplug.d/ type of notification?
Oh, and attributes. How about we just change kobject_hotplug() to be: int kobject_hotplug(const char *action, struct kobject *kobj, struct attribute *attr); and if we set attr to be a valid pointer, we make the DEVPATH paramater contain the attribute name at the end of it.
I'd be glad to accept a patch that implements this.
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):
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.
On Sat, Sep 04, 2004 at 02:54:33AM +0200, Greg KH wrote:
> How about you just add the ability to send hotplug calls across netlink? > Make it so the kobject_hotplug() function does both the exec() call, and > a netlink call (based on a config option for those people who like to > configure such stuff.)
> That way, programs who want to listen to netlink messages to get hotplug > events do so, and so does programs who want to do the /etc/hotplug.d/ > type of notification?
> Oh, and attributes. How about we just change kobject_hotplug() to be: > int kobject_hotplug(const char *action, struct kobject *kobj, struct attribute *attr); > and if we set attr to be a valid pointer, we make the DEVPATH paramater > contain the attribute name at the end of it.
If we add this to the kobject_hotplug function, how do we prevent the execution of /sbin/hotplug for ksets that have positive hotplug filters? So I've created a new function for now: int kobj_notify(const char *signal, struct kobject *kobj, struct attribute *attr)
which can be used from the subsystems. This function is also called for the normal /sbin/hotplug event. (The subsystems may provide a additional environment for the /sbin/hotplug events, this is ignored by now.)
Here is the debug output of a simple listener, while inserting a USB-memory-stick, mounting, unmounting and removing it:
[root@pim kdbusd]# ./kdbusd main: [1094349091] 'add' from '/org/kernel/devices/pci0000:00/0000:00:1d.1/usb3/3-1' main: [1094349091] 'add' from '/org/kernel/devices/pci0000:00/0000:00:1d.1/usb3/3-1/3-1:1.0' main: [1094349091] 'add' from '/org/kernel/class/scsi_host/host2' main: [1094349091] 'add' from '/org/kernel/devices/pci0000:00/0000:00:1d.1/usb3/3-1/3-1:1.0/host2/2:0:0:0 ' main: [1094349091] 'add' from '/org/kernel/block/sda' main: [1094349091] 'add' from '/org/kernel/class/scsi_device/2:0:0:0' main: [1094349091] 'add' from '/org/kernel/class/scsi_generic/sg0' main: [1094349092] 'add' from '/org/kernel/block/sda/sda1'
main: [1094349094] 'claim' from '/org/kernel/block/sda/sda1' main: [1094349101] 'release' from '/org/kernel/block/sda/sda1'
main: [1094349106] 'remove' from '/org/kernel/class/scsi_generic/sg0' main: [1094349106] 'remove' from '/org/kernel/class/scsi_device/2:0:0:0' main: [1094349106] 'remove' from '/org/kernel/block/sda/sda1' main: [1094349106] 'remove' from '/org/kernel/block/sda' main: [1094349106] 'remove' from '/org/kernel/devices/pci0000:00/0000:00:1d.1/usb3/3-1/3-1:1.0/host2/2:0:0:0 ' main: [1094349106] 'remove' from '/org/kernel/class/scsi_host/host2' main: [1094349106] 'remove' from '/org/kernel/devices/pci0000:00/0000:00:1d.1/usb3/3-1/3-1:1.0' main: [1094349106] 'remove' from '/org/kernel/devices/pci0000:00/0000:00:1d.1/usb3/3-1'
#define MAX_LINKS 32 diff -Nru a/init/Kconfig b/init/Kconfig --- a/init/Kconfig 2004-09-05 03:54:23 +02:00 +++ b/init/Kconfig 2004-09-05 03:54:23 +02:00 @@ -195,6 +195,21 @@ agent" (/sbin/hotplug) to load modules and set up software needed to use devices as you hotplug them.
+config KOBJ_NOTIFY + bool "Kernel Events Layer" + depends on NET && HOTPLUG + default y + help + This option enables the kernel events layer, which is a simple + mechanism for kernel-to-user communication over a netlink socket. + The goal of the kernel events layer is to provide a simple and + efficient events system, that notifies userspace about kobject state + changes e.g. hotplug events, power state changes or block device + claiming (mount/unmount). + + Say Y, unless you are building a system requiring minimal memory + consumption. + config IKCONFIG bool "Kernel .config support" ---help--- diff -Nru a/kernel/Makefile b/kernel/Makefile --- a/kernel/Makefile 2004-09-05 03:54:23 +02:00 +++ b/kernel/Makefile 2004-09-05 03:54:23 +02:00 @@ -24,6 +24,7 @@ obj-$(CONFIG_AUDIT) += audit.o obj-$(CONFIG_AUDITSYSCALL) += auditsc.o obj-$(CONFIG_KPROBES) += kprobes.o +obj-$(CONFIG_KOBJ_NOTIFY) += kobj_notify.o
ifneq ($(CONFIG_IA64),y) # According to Alan Modra <a...@linuxcare.com.au>, the -fno-omit-frame-pointer is diff -Nru a/kernel/kobj_notify.c b/kernel/kobj_notify.c --- /dev/null Wed Dec 31 16:00:00 196900 +++ b/kernel/kobj_notify.c 2004-09-05 03:54:23 +02:00 @@ -0,0 +1,88 @@ +/* + * kernel/kobj_notify.c - sysfs event delivery via netlink socket + * + * Copyright (C) 2004 Red Hat, Inc. All rights reserved. + * Copyright (C) 2004 Novell, Inc. All rights reserved. + * + * Licensed under the GNU GPL v2. + * + * Authors: + * Robert Love <r...@novell.com> + * Kay Sievers <kay.siev...@vrfy.org> + * Arjan van de Ven <arj...@redhat.com> + */ + +#include <linux/spinlock.h> +#include <linux/socket.h> +#include <linux/skbuff.h> +#include <linux/netlink.h> +#include <linux/string.h> +#include <linux/kobject.h> +#include <net/sock.h> + +static struct sock *kobj_notify_sock = NULL; + +static int do_kobj_notify(const char *signal, struct kobject *kobj, + struct attribute *attr, int gfp_mask) +{ + const char *path; + struct sk_buff *skb; + char *buffer; + int len; + + if (!kobj_notify_sock) + return -EIO; + + path = kobject_get_path(NULL, kobj, gfp_mask); + if (!path) + return -ENOMEM; + + len = strlen(signal) + 1; + len += strlen(path) + 1; + if (attr) + len += strlen(attr->name) + 1; + + skb = alloc_skb(len, gfp_mask); + if (!skb) + return -ENOMEM; + + buffer = skb_put(skb, len); + if (attr) + sprintf(buffer, "%s\n%s/%s", signal, path, attr->name); + else + sprintf(buffer, "%s\n%s", signal, path); + kfree(path); + + return netlink_broadcast(kobj_notify_sock, skb, 0, 1, gfp_mask); +} + +int kobj_notify(const char *signal, struct kobject *kobj, + struct attribute *attr) +{ + return do_kobj_notify(signal, kobj, attr, GFP_KERNEL); +} + +EXPORT_SYMBOL(kobj_notify); + +int kobj_notify_atomic(const char *signal, struct kobject *kobj, + struct attribute *attr) +{ + return do_kobj_notify(signal, kobj, attr, GFP_ATOMIC); +} + +EXPORT_SYMBOL(kobj_notify_atomic); + +static int __init kobj_notify_init(void) +{ + kobj_notify_sock = netlink_kernel_create(NETLINK_KOBJ_NOTIFY, NULL); + + if (!kobj_notify_sock) { + printk(KERN_ERR + "kobj_notify: unable to create netlink socket!\n"); + return -ENODEV; + } + + return 0; +} + +core_initcall(kobj_notify_init); diff -Nru a/lib/kobject.c b/lib/kobject.c --- a/lib/kobject.c 2004-09-05 03:54:23 +02:00 +++ b/lib/kobject.c 2004-09-05 03:54:23 +02:00 @@ -13,6 +13,7 @@ #undef DEBUG
On Sat, 2004-09-04 at 02:54 +0200, Greg KH wrote: > So, we're back to the original issue. Why is this kernel event system > different from the hotplug system? I would argue there isn't one, > becides the transport, as you seem to want everything that we currently > provide in the current kobject_hotplug() call.
> But transports are important, I agree.
> How about you just add the ability to send hotplug calls across netlink? > Make it so the kobject_hotplug() function does both the exec() call, and > a netlink call (based on a config option for those people who like to > configure such stuff.)
This smells.
Look, I agree that unifying the two ideas and transports as much as possible is the right way to proceed. But the fact is, as you said, transports _are_ important. And simply always sending out a hotplug event _and_ a netlink event is silly and superfluous. We need to make up our minds.
I don't think anyone argues that netlink makes sense for these low priority asynchronous events.
I'd prefer to integrate the two approaches as much as possible, but keep the two transports separate. Use hotplug for hotplug events as we do now and use kevent, which is over netlink, for the new events we want to add.
Maybe always do the kevent from the hotplug, but definitely do not do the hotplug from all kevents. It is redundant and extra overhead.
Doing both simultaneous begs the question of why have both. Picking the right tool for the job is, well, the right tool for the job.
