Subject: Re: Alternative approach for interface events
To: None <email@example.com>
From: Pavel Cahyna <firstname.lastname@example.org>
Date: 09/21/2004 09:29:34
> In message <email@example.com>Pavel Cahyna writes
> >> (Currently knote(9) can only add events to a kqueue opened from
> >> userspace, but extending this API to be able to run arbitrary kernel
> >> functions instead would probably be possible. I have an (untested)
> >> patch which should do exactly this.)
> >Here is the patch. It has been compile-tested and all the kqueue
> >regression test complete successfully. "options KCONT" is needed.
> You will have great difficulty making this MI, unless we resolve the
> issue of whether IPLs are sufficiently orderd on all platforms; and
> kcont vs. generic softints, particuarly on mac-ppc. Though the latter
> may already be fixed (Matt Thomas had local code in May, but I didnt
> watch for a commit).
I don't think it's a big problem. I don't suppose that users of such API
would need the deferred execution capability of kconts (any other desired
IPL than KCL_IPL_IMMEDIATE), and if they do, they would have to wait until
this issue is resolved. It's true that kconts would not be needed for what
I did, but they are here, I was lazy to invent another callback mechanism
and the deferred execution capability doesn't add much overhead.
> >It renames kcont_run to kcont_run_all, adds a kcont_run function which
> >runs only one kcont (I believe this is a reasonable change to the kcont
> If you're going to change the semantics that far, I would prefer we
> call the new function kcont_run_one(), and if desired, rename
> kcont_run() to kcont_run_all(). (Personally, I think the current name
> is fine.) Please do at least the kcont_run_one() change before
OK, no problem. kcont_run just sounds like "run a kcont" not "run many
> committing the proposed change.
I don't have commit rights, and I will keep that in mind before submitting
any "final" patch (which this one certainly isn't).
> Also, dont forget to update kcont(9) and knote(9).
> Since kqueue(2) ad knote(9) is not optional, you should not commit the
> proposed a change until after kcont(9) is IP-safe on all ports, and
> made non-optional on all ports.
You mean IPL-safe? Until then there could be added a
(desired_ipl==KCL_IPL_DEFER_PROCESS)) to the kcont functions. I believe
that kconts are useful even without deferring to soft-interrupts, and that
APIs should not be multiplied unnecessarily.