Subject: Re: Importing kqueue's from FreeBSD...
To: None <email@example.com, firstname.lastname@example.org>
From: None <email@example.com>
Date: 03/19/2001 16:21:45
At 21:31 +0000 3/15/01, firstname.lastname@example.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.