Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 05 Jul 2001 23:34:52 -0700
From:      Julian Elischer <julian@elischer.org>
To:        Peter Wemm <peter@wemm.org>
Cc:        Jason Evans <jasone@canonware.com>, current@FreeBSD.ORG
Subject:   Re: RFC: Kernel thread system nomenclature.
Message-ID:  <3B455C0C.C5E8197C@elischer.org>
References:  <20010706010723.8626D3809@overcee.netplex.com.au>

next in thread | previous in thread | raw e-mail | index | archive | help
Peter Wemm wrote:
> 
> Jason Evans wrote:
> > On Mon, Jul 02, 2001 at 02:16:16PM -0700, Julian Elischer wrote:
[...]
> > I think there is a clear argument for #1 to be "struct proc".  I don't much
> > care what #2, #3, and #4 are called.
> >
> > I am of the rather strong opinion that calling #3/#4 "struct proc" is a bad
> > idea in the long run.  Yes, it would reduce the diffs, but it would be
> > terribly confusing to those who weren't versed with the development history
> > of KSEs.
> 
> Also keep in mind that netbsd use 'struct lwp *' for #3/#4 (SA has these
> combined into one entity).  If there is an easy way to not be gratuitously
> different I think it would be worth it.

Also comments by several others..

Ok so here's how it looks to me now: (still not final)

#1    struct proc   (decided)
#2    struct schedgrp ,lpwg (lwp-group), prigrp (priority-group)
	subproc (subprocess)
#3    struct upctx (upcall-context), virtcpu, thrdslot (thread slot)
#4    struct lwp    (decided)

usually the 'lwp' will be passed around so diffs to NetBSD will be minimalised.


my favourites are:
proc, subproc, lwcpu, lwp

lwps are parcelled out to lwcpus to run when the appropriate subproc is
scheduled.


-- 
+------------------------------------+       ______ _  __
|   __--_|\  Julian Elischer         |       \     U \/ / hard at work in 
|  /       \ julian@elischer.org     +------>x   USA    \ a very strange
| (   OZ    )                                \___   ___ | country !
+- X_.---._/    presently in San Francisco       \_/   \\
          v

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3B455C0C.C5E8197C>