On 2001-Jul-06 18:14:03 -0700, Julian Elischer <[EMAIL PROTECTED]> wrote:
>#3 ??? (thread carrier (spindle? :-)) or thread-processor
A spindle is a physical disk drive (or at least independent head
assembly) - I/O rates are associated with spindles rather than
[virtual/RAID] disks.
If we're goi
John Baldwin wrote:
> One other note. #2 is conceptually a related group of
> #4's, so I think it's name should reflect that. (It's
> view as a group of #4's is more important than as being
> a part of #1.) So, if you go with lwp (yuck) for #4, #2
> should be lwpgrp or some such. I still think
John Baldwin wrote:
> >#3struct upctx (upcall-context), virtcpu, thrdslot (thread slot)
> >#4struct lwp(decided)
> >
> > usually the 'lwp' will be passed around so diffs to NetBSD will be
> > minimalised.
>
> One thing to note is that as Vahalia (sp?) points out, lwp
> on SVR4 and Sol
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 clos
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 ma
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 ks
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.
> --
> Dan Eischen
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
wi
On Fri, 6 Jul 2001, Julian Elischer wrote:
> On Fri, 6 Jul 2001, John Baldwin wrote:
> > One other note. #2 is conceptually a related group of #4's, so I think it's
> > name should reflect that. (It's view as a group of #4's is more important than
> > as being a part of #1.) So, if you go with
On 07-Jul-01 Julian Elischer wrote:
>
>
> On Fri, 6 Jul 2001, John Baldwin wrote:
>
>> >
>> > my favourites are:
>> > proc, subproc, lwcpu, lwp
>> >
>> > lwps are parcelled out to lwcpus to run when the appropriate subproc is
>> > scheduled.
>>
>> One other note. #2 is conceptually a relat
On 07-Jul-01 Julian Elischer wrote:
> that reminds me..
>
> The reason I want to work out the names now is because I have a system up
> and running with the process structure split into these pieces and I wan
> teh names finalised before I take the next step which involves editing
> almost every
On Fri, 6 Jul 2001, John Baldwin wrote:
> >
> > my favourites are:
> > proc, subproc, lwcpu, lwp
> >
> > lwps are parcelled out to lwcpus to run when the appropriate subproc is
> > scheduled.
>
> One other note. #2 is conceptually a related group of #4's, so I think it's
> name should refle
that reminds me..
The reason I want to work out the names now is because I have a system up
and running with the process structure split into these pieces and I wan
teh names finalised before I take the next step which involves editing
almost every kernel file.
To Unsubscribe: send mail to [EM
On 06-Jul-01 Julian Elischer wrote:
> 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.
>> >
>> >
On 06-Jul-01 Julian Elischer wrote:
> 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.
>> >
>> >
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
Jason Evans wrote:
> On Mon, Jul 02, 2001 at 02:16:16PM -0700, Julian Elischer wrote:
> >
> > Almost all of the current 'proc' pointers being passed around the system
> > in syscalls will be changed to the #4 item. In addition, most accesses to
> > curproc would point to a curthread (curr-#4) or
On 2001-Jul-02 14:16:16 -0700, Julian Elischer <[EMAIL PROTECTED]> wrote:
>The time has come (now that we have a design) to assign names to the
>various entities that will be created when we implement the
>(current name) KSE code.
I'm reasonably sure that there's prior art here. What do other O
On Mon, 2 Jul 2001, Alfred Perlstein wrote:
> Scheduling control block. Remove 'Process' because as far as I
> understand it, it's not really a process, it's a group of threads.
SCB is SCSI Command Block.
--
Dan Eischen
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-
On Mon, 2 Jul 2001, Julian Elischer wrote:
>
> The time has come (now that we have a design) to assign names to the
> various entities that will be created when we implement the
> (current name) KSE code.
>
> I have already done initial work on this and have a system running with
> the proc str
On Mon, 2 Jul 2001, Alfred Perlstein wrote:
> Oh what a bikeshed you've begun. :)
>
> Proc, this keeps the unix convention, a task is confusing, at least
> to me because afaik in Linux a task is actually a thread. Keeping it
> as proc will also require fewer changes to the code. :)
Actually t
Oh what a bikeshed you've begun. :)
* Julian Elischer <[EMAIL PROTECTED]> [010702 14:39] wrote:
>
> The time has come (now that we have a design) to assign names to the
> various entities that will be created when we implement the
> (current name) KSE code.
>
> I have already done initial work
The time has come (now that we have a design) to assign names to the
various entities that will be created when we implement the
(current name) KSE code.
I have already done initial work on this and have a system running with
the proc structure split into 4 parts.
The names of these parts nee
22 matches
Mail list logo
