Re: [patch] kernel events layer

Tim Hockin
2004-07-24T17:46:49Z

On Sat, Jul 24, 2004 at 11:45:53AM -0400, Robert Love wrote:
>
> Not everything has a corresponding sysfs name, which really makes the
> whole notion moot.

The things that do can use it, though. Here's a place where inconsistency
(if present) is pointless.1

> I might not of been clear - path name of the file in the kernel source
> tree. So if you add an event to fs/open.c the path is
> "/org/kernel/fs/open". This is a pretty generic naming scheme that
> ensures names will be unique within the kernel and will not conflict
> with names outside the kernel (e.g. the global URI space of whatever is
> used in user-space).

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.

> "high" is only an arbitrary string if it is not standardized. If the
> temperature event is defined to come from such and such an interface,
> with such and such values, it is all very easy to use. I mean, this is
> how object systems work today.

As long as we're religious about making every subsystem standardize these
names, it should be ok. Another reason to macro-ize. There are way too
many people touching too much code that might take advantage of a generic
kernel->user event to rely on soft rules.

> > In the case of a file close, the object name is the file path and the
> > attribute could be the ctime, but it needs more thinking.
>
> This is where the sysfs naming scheme breaks down. You now have two
> different namespaces - kobjects and files on a filesystem. We really
> need something a lot simpler. Let user-space map stuff around if we
> want that.

Assuming that we're going to be doing file notifications via this,
wouldn't something like "/fs/file close /path/to/foo" be right(er)?

Cheers
Tim