On Mon, Mar 19, 2001 at 01:40:10PM -0800, Charles M. Hannum wrote:
> On Mon, Mar 19, 2001 at 04:21:45PM -0000, eeh@netbsd.org wrote:
> > 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.
> 
> As I've already pointed out elsewhere, copying strings in and out of
> the kernel for poll(2)/select(2)-like functionality would be a
> significant CPU hit, which partly defeats the point of doing this in
> the first place.

In order to solve eeh's preferences, there was an alternative
solution; support a string->kqueuefilter lookup:

	struct kevent event[1];
	int fd, type;

	kq = kqueue();
	if (kq < 0)
		err(1, "kqueue");

		/* the following is new */
	type = kqueue_filtertype("read");

	event[0].ident = fd;
	event[0].filter = type;		/* instead of EVFILT_READ */
	event[0].flags = EV_ADD | EV_ENABLE;
	if (kevent(kq, event, 1, NULL, 0, NULL) < 0)
		err(1, "kevent");

In this case, int kqueue_filtertype(const char *) checks the kernel
for a list of already registered filters and returns an int to be used
as the filter type. When support is added for the functionality to
allow extra filters to be registered, that registration function could
also take the string as the identifier.

It shouldn't matter if the string->id conversion returns different
numbers for the same string across reboots; it only has to be
consistent per reboot.

I think this solve's eeh's (and thorpej's) concerns about allowing
arbitrary filters to be defined, without requiring strings to be used
at all times. There's still a potential for namespace clash (if two
third party lkm vendors choose the same string), but it's far less
likely than two vendors choosing the same int.


PS: excuse me if this isn't coherent; I'm feeling unwell.