KSE/ia64: a quick update

[Marcel Moolenaar]

On Wed, Aug 06, 2003 at 02:42:45PM -0700, Julian Elischer wrote:
> 
> Originally we would not do an upcall unless the
> kernel was neterred from a syscall, however David added soem code so
> that at a clock interrupt, if the mailbox indicates that it has had
> enough time, An UPCALL context is belatedly made and saved and an upcall
> results..

Ah, so I have David to thank for the added complexity... :-)

> > But both are async frames on alpha. The only difference is the
> > layout, not what's put in it. On ia64 the layout is always the
> > same, but we don't populate everything all the time.
> 
> So how does a returning thread know what to restore?

So far it has always been a sync context, so all that needed to
be restored were the special and the preserved registers. I
added the return registers just recently. The sync contexts
don't have any optional fields. It's the async contexts that
make things complicated. I just have to add flags and/or
actually use the flags that have been defined already.

> > Yes. That too. I had a brainwave: We still support the old
> > syscall path, which is based on the break instruction. It's
> > a trap. So, we can use the break instruction to trap into
> > the kernel, executing the setcontext() syscall and go back
> > to the interrupted context without any hackery. This at
> > least resolves the problem of having 2 paths into the
> > kernel: we take a trap to restore a context created by
> > a trap. I guess I won't obsolete the old syscalls anymore :-)
> > 
> > Alas, I forgot about the mailbox pointer... We don't have a
> > syscall for that. I could probably put the info in the context
> > itself, set a flag and enhance setcontext() to do it atomically
> > as a possibly undocumented feature/extension to support KSE.
> > Hmmm...
> 
> you're somewhere near here now aren't you?
> (I think you said san Mateo but I could be wrong)

I live in Mountain View. San Mateo relates to BSDcon.

> Maybe we could get to gether some time and walk through
> this.. A whiteboard is always easier to understand.

That's probably not a bad idea. I'll this off-list, unless it's
beneficial for others as well and we can meet with one or two
more.

-- 
 Marcel Moolenaar	  USPA: A-39004		 marcel at xcllnt.net