Re: [patch] kernel events layer

[Tim Hockin <thockin@hockin.org>]

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