> In message <pan.2004.09.20.23.44.20.277888@st.mff.cuni.cz>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
> >API) 
> 
> 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
kconts".

> 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).

Of course.

> 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
KASSERT((desired_ipl==KCL_IPL_IMMEDIATE) ||
(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.

Bye	Pavel