At 01:04 PM 1/28/2004, Jonathan Stone wrote:

>The code below is a sample implementation of ``continuation-passing''
>for the NetBSD kernel. If you're not familiar with languages that have
>functions, closures, and continuations as first-class objects, think
>of this as a framework for handling ``callback functions'': specifically
>creating, enqueing, managinging, and deferring callbacks to some lower
>interrupt priority.

I've now delved deeper into this and I wonder.

kcont's overlap generic soft interrupts considerably.  In fact, except
for the fact that generic soft interrupts are not available on every
platform, I can't see any reason why you would use kcont's instead of
softintrs.

kcont's rely on the fact the IPLs are defined in increasing order.
That is not a requirement and in fact one port (macppc) has its IPLs
defined in decreasing order.

The only advantages I can see for kcont's is allowing for continuation
in a kthread and continuation at IPLs above IPL_SOFT*.  The former
could be done by extending softintrs to be include IPL_NONE.  I'm not
sure the latter is needed.

I wonder if we should have IPL_SOFTBIO and IPL_SOFTTTY and require that
IPL_<!SOFT>FOO be only used when hardware interrupt exclusion is needed
(ie. talking to a device).  The real work though needs to be at
IPL_SOFT<FOO>.

I also dislike that kcont can be allocated on the fly (unlike  softintr's
which have to be establish in a sleepable context).

At this point, I would instead make generic softintr required fuctionality,
extend their capability, and kill kconts.  Or kill generic softintr and
use kconts instead.  One or other but not both.

-- 
Matt Thomas                     email: matt@3am-software.com
3am Software Foundry              www: http://3am-software.com/bio/matt/
Cupertino, CA              disclaimer: I avow all knowledge of this message.