[[ changes to kcont or kqueue should, imho, properly be discussed on
tech-kern rather than tech-net. cc: and replhy-to: set accordingly;
apologies to anyone bothered by seeing this twice.]]


In message <pan.2004.09.20.23.44.20.277888@st.mff.cuni.cz>Pavel Cahyna writes
>On Mon, 20 Sep 2004 21:23:54 +0000, Pavel Cahyna wrote:
>
>> (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).


>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
committing the proposed change.

Also, dont forget to update kcont(9) and knote(9).



>and adds a kn_kcont field to struct knote. Set this field to any
>kcont you want (but always call kcont with env_arg set to this knote) and
>it will be run when knote(9) is called on this knote. The kqueue system
>has been changed to set kn_kcont to a kcont which queues the knote to a
>kqueue.

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.