On Fri, Jan 13, 2006 at 11:57:31AM +0900, YAMAMOTO Takashi wrote:
> > I don't think anything in the tree uses kconts.  They were intended
> > to replace the hand-coded continuations in the FAST_IPSEC code, and
> > there's also a splice() implementation that uses them, but it's all
> > been on hold for years because we can't establish a single ipl hierarchy
> > across ports, and the generic kcont code doesn't work without that.
> > 
> > It has to happen.  I hope someone causes it to -- soon.
> 
> was there a concensus to move from softint to kcont?

I don't know.  I certainly wasn't under the impression that we intended
to leave them in the tree, and broken, indefinitely -- were you?  At the
same time, I think that -- though working with them can be frustrating
and bizarre at first as one learns a new style of programming -- in
fact continuations are very elegant and make some kinds of code much
easier to write.  I'd like to have the splice() implementation in our
tree, I'd like to see the hand-coded continuations in the fast-ipsec
code go away in favor of the much cleaner kcont interface, and there are
other parts of the tree that could benefit as well.  In contrast, every
time I look at one of our uses of softints it looks hard to read, and
(to my mind) somewhat clumsy, too -- like a series of similar one-off
hacks that have propagated through the tree because by now we're used
to them.

If it has to be either-or, I guess we should discuss this here, but also
ask core for a decision; it's the sort of decision the technical leadership
of the Project should make, no?

-- 
  Thor Lancelot Simon	                                     tls@rek.tjls.com

  "We cannot usually in social life pursue a single value or a single moral
   aim, untroubled by the need to compromise with others."      - H.L.A. Hart