At 21:31 +0000 3/15/01, eeh@netbsd.org wrote:
	>I think that needing to add new event types to <sys/event.h> is
	>a problem.  The issue is not being able to handle every event that
	>anyone can think of but being able to add events without fears of
	>conflicts.  Since the interface is exported to userland, we shouldn't
	>need to recompile the universe because someone added a new event type.
	>I'm afraid that this limitation will eventually require the interface
	>be replaced by something more flexible, so I really would like to
	>have that issue addressed first.

	I'd like to amplify Eduardo's point, and add that since we work hard 
	on binary compatability with Linux and UNIX-like OS's, we will need 
	to coordinate event identifier assignment with everyone else who 
	wants to use this API, or resign ourselves to maintaining event 
	translation tables in the emulation layers.

	We might want to consider establishing a common registry for stuff 
	like this (system call numbers, event identifiers, device major 
	numbers, etc) among the *BSD's...

Actually, that was not exactly what I was looking for.  Registries
always have problems since generating a consensus about who 
controls the registry is difficult, and experimental code is
usually built before registering with the authority.

I would prefer something that uses strings to identify events
to userland so new event types could be created without
much fear that they would conflict.  By qualifying the
event by a subsystem type, the probablility of conflict
between two different events would be minimal.

In the kernel, the strings could be hashed and manipulated
by the hash values to speed processing.

Eduardo