Daniel Eischen wrote:
> On Fri, 6 Jul 2001, Peter Wemm wrote:
> > Julian Elischer wrote:
> > >
> > >
> > > On Fri, 6 Jul 2001, Daniel Eischen wrote:
> > > >
> > >     ->proc->
> > > >   ->thrgrp->
> > > >   ->thr->
> > > >   ->thrctx->
> > > >
> > > interesting, though the thrctx maps most closely to a userland thread.
> > > there may be many threads running on each #3.
> >
> > IMHO, I like this less than kse/kseg/ksec/proc.  Remember.. these are
> > not thread specific.. they can be used to implement aio etc as well.
> >
> > The KSE paper's definitions of things are pretty clear.  If we're not
> > going to use something netbsd compatable, then IMHO we should stick to
> > the design paper.
> That was my first thought also ;-)
> > The only variation that I think I'd find appealing would be to try
> > and make the kseg/ksec difference stand out more.  ksegrp/ksectx is less
> > likely to be confused at a casual glance.
> >
> > I'm not really sure that we can use the 'struct lwp' name in a compatable
> > way with NetBSD.  It would be even worse if we both had 'struct lwp'
> > but ours was different to theirs.
> NetBSD doesn't (yet) have an idea of a KSE group.  We could just
> replace our usage of KSE with LWP:
>   proc->
>   lwpgrp->
>   lwp->
>   lwpctx->
> If NetBSD ever folded in our KSE group support, wouldn't that be the
> most compatible?

heh.. unlikely
as to which (#4 or #3) is the lwp, I think that #4 is the lwp
as it is what is put on the sleep queue, and it is what has the 
kernel stack and context to be restarted.

Their equivalent to #3 is a couple of fields in the 'sadata' struct
and the 'struct sa' that is passed around. The define a 'per process'
upcall location and have a predefined number of stacks passed to the 
kernel to use on these upcalls. We define a separate preloaded context
for each #3 to come back on.

They directly schedule all lwps on the run queue, thereby giving them
all 'process' weight by default. We do it via #2, which allows 
us to keep them fairer (if we want).

> > ... etc...
> >
> > Look for these in particular:
> > Index: sys/sys/lwp.h
> > Index: sys/sys/proc.h
> > Index: sys/sys/sa.h
> > Index: sys/sys/savar.h

yep looked at them. interesting but predictable if you've read the sa paper.
I still don't understand the solaris lwp mode though...

> >
> > If we dont do similar structure member naming, then there is no point
> > using the same structure names as that will just increase the confusion.

I think that their lwp and or #4 are really pretty similar in a lot of ways
but as you suggest, maybe not similar enough to  keep the name the same.

> >
> > NetBSD's structure is different too.. They have implelemted both
> > Solaris-style LWP's and SA's over the top of the same low level entity.
> I like that they use a ucontext_t for storing the context also.
> Julian, can we please do the same?  We'll probably also need to
> use a spare slot in ucontext/mcontext for a flags word (floating
> point register validity?).

I was always planning to use one, the only difference is where it is stored..

We bypass the need to have a trampoline by knowing in advance where to copy out
the ucontext to. We can also report back many blocked calls at once
and many completed ones at the same time. The ucontext is stored directly
back to user space rather than copied to the stack, and then copied to the 
thread storage..

The thread storage contains a ucontext. They use it indirectly, while we use it

we COULD put it on the stack like they do, but I think our idea is more

ok, so to the names..

#1 proc
#2 ksegrp 
#3 kse
#4 ksectx

shorter abreviations:
(this is what Jasone proposed on my original suggestions.)

but at least this way I won't get grief on it and
it also matches what I've already coded :-)

> --
> Dan Eischen

+------------------------------------+       ______ _  __
|   __--_|\  Julian Elischer         |       \     U \/ / hard at work in 
|  /       \ [EMAIL PROTECTED]     +------>x   USA    \ a very strange
| (   OZ    )                                \___   ___ | country !
+- X_.---._/    presently in San Francisco       \_/   \\

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to