Messages in this thread | | | Date | Sun, 25 Jul 2004 11:11:39 -0700 | From | Tim Hockin <> | Subject | Re: [patch] kernel events layer |
| |
On Sat, Jul 24, 2004 at 02:19:43PM -0400, Robert Love wrote: > If some things can use the kobject path, we can use it in the argument > field. I am cool with that - that is exactly what I want, in fact. But > what we use as the naming convention needs to be something we can use > uniformly. Unfortunately not everything has a kobject backing it, and > we cannot change that.
yeah. I suppse that's true. What's the meaning of the 'source' object, generically?
> > This immediately strikes me as a really bad idea. Stuff moves between > > files. Two files might really want to signal an event from the same > > source. > > The signal name would be different.
I'm not sure why, yet, it just seems like a bad idea.
> I like your macro-izing idea and the notion of standardizing. Someone > else brought up a good example: we want _all_ disk drivers to emit the > exact same signal for e.g. "disk full" so user-space can react to it. > It needs to be consistent. At least for driver error logging, we > definitely want standards and macro-izing. The translation point is > another good reason for it.
So, when I was at Sun (no, I'm not at Sun anymore) there was lots of talk of driver hardening and fault management. At the time, the team in question looked at the various event systems that currently exist in the kernel or in some patches. This list might be incomplete, but it's off the top of my head.
- Netlink - ACPI (/proc/acpi/event) - hotplug - IPMI (not merged maybe?) - relayfs (not merged) - evlog (last I saw, this was in big flux)
Now you're proposing netlink as the kevent subsystem.
Wouldn't it be nice if everything could converge? Ok maybe not EVERYTHING, but some of these?
These are the things I can see kevents being used for:
- Stateless messages which only matter if someone is listening. Examples of this are "media changed" and stuff like that.
- Fault and error that matter no matter what, and can not afford to be dropped. Examples are things like ECC errors, significant driver/subsystem errors, etc.
- System state messages, which really do want someone to be listening, but are otherwise discoverable. Examples of this are "disk full" and similar.
So can kevents be used for all of these? The fact that netlink does not buffer events if there are no listeners (not saying it should..) makes it unreliable for fault events. Can these all be converged?
Sorry for rambling - kernel events has been on my mind for some time. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |