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 on this and have a system running with
> the proc structure split into 4 parts.
>
> The names of these parts need to be fully decided and agreed upon now
> while the changes are limited to 2 files :-) The next change requires
> editing almost every file in the kernel. The KSE names were a temporary
> measure to identify these while their functions were being decided.
>
>
> Here are the entities, a decription of what they do, and some suggested
> names:
>
> 1) This structure 'owns' all the resources that are relavent to the
> process. It owns the credentials, the VM space, the file desriptors,
> (possibly the signal state), the parent process, the child processes
> etc. etc.
>
> Suggested names: proc, task (others?)
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. :)
>
> 2) The second structure owns the scheduling parameters. All scheduling
> decisions are made according to information held in this structure. The is
> by default one of these per each of the above (#1) structure. However the
> threads library may make more should it wish to shedule some threads at a
> different priority. Each of these competes with the weight of a process in
> the system scope. In the case where there are not per-cpu run queues, THIS
> would be put on the run queues. There may be between 1 and M of these
> where M is the remaining rlimit on processes. (they count as processes
> against the rlimits)
>
> Suggested names: schedblock (SB),
> Kernel Schedulabale Entity Group (KSEG),
> KSE (confusing but acurate),
> SchedEntry, (SE?),
> Process Schduling control block (pscb)
Scheduling control block. Remove 'Process' because as far as I
understand it, it's not really a process, it's a group of threads.
> 3) The third structure is a container for running code contexts. The
> concurrency of a MP machine can be exploited by having multiple of these
> entities, each of which most be run on a different processor. With per-CPU
> run queues, these would be on the queues, but the controling parameters
> are inherrited from the 2nd structure. There may be between 1 and N (where
> N is the number of processors) of these entities per each of the 2nd
> structure type. Eligible contexts are run in either kernel or user mode
> when this is scheduled. Each of these has a separate upcall context stored
> for communication with the Userland scheduler.
>
> Suggested names: Kernel Schedulable Entity(KSE),
> thread container(TC),
> Scheduler Virtual processor(SVP),
> Scheduler Slot(schedslot, ss?)
> Thread processor (tp?)
I think thread container makes the most sense.
> 4) The last entity is the 'kernel context' structure.
> This contains the kernel stack for whatever thread of execution is being
> run and is what is saved onto the sleep queues when a tread of execution
> blocks. All the context needed to restart a thread is saved in this.
> In the current system this information is stored in a combination of the
> proc struct, the U area and the kernel stack. There can be an almost
> unlimited (resource limited) number of these which would indicate
> a large number of blocked syscalls. They are allocated to the #2
> structure and may run under more than one of the #3 entities during the
> course of a syscall if there are context switches. they would have some
> affinity to the last #3 they ran on for cache reasons, but conld be
> switched to another #3 that is connected to the same #2 if it were idle.
>
> Suggested names: Thread Context Block (TCB)
> Kernel Schedulabel Entity Context (KSEC)
> Thread Context (TCTX)
thread/curthread, if you think about it, this is what it boils down to
at the most basic level and therefore keeps the terminology simple.
> Any more suggestions are most welcome! (but seeing as how I'm doing the
> code I will select as I see fit at the end of the discussion.
>
> 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 a curr#3, so the names
> selected will be used a lot.
> The exctent of these edits almost makes it worthwhile to call the #4 item
> 'struct proc' as the size of the diff would be MASSIVLY reduced.. :-).
> (everyhting to do with sleeping, blocking, and waking up would
> avoid changes, and everywhere a syscall passes down "struct proc *p"
> would avoid changes.
I agree, but keeping the old terminology to describe things isn't
proper and can lead to code mistakes and confusion as a thread is
not really a process.
It gets sort of confusing, as I'm not really sure where the thread
actually is, #3 or #4, it's actually 4, however you can only run
'amount of #3' threads at the same time.
--
-Alfred Perlstein [[EMAIL PROTECTED]]
Ok, who wrote this damn function called '??'?
And why do my programs keep crashing in it?
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message