[TUHS] Reading UNIX V6: Does eash process has its own user structure, or all the processes share one copy of it?

[TUHS] Reading UNIX V6: Does eash process has its own user structure, or all the processes share one copy of it?

[jigsaw]

hi All,

Again, I run into problems when reading slp.c and savu/retu.

Actually, I have 3 questions.

First, I doubt whether all processes share one "u" or each process has
its own "u".

line 0402: One allocated per process.

It seems that each process has its own user structure.

But the "u" is defined as a universal variable (line 0459), and the
line 0407 clearly states that the "u" resides at virtual kernel loc
140000.

So isn't it saying that there's only one "u" in the core memory?


This concept is very important, because it's bound tightly with
savu/retu mechanism.

---------------------------------------------------------------------------

Now comes the second question:

The savu procedure is supposed to save r5 and sp to u.u_rsav,
and the retu is supposed to reset the r5 and sp with the saved values.

If each process has its own u, then savu/retu simply work fine.

But if all processes share one u, the newest call to savu will
overwrite the previously saved values of r5 and sp, so that retu is
not able to get back the r5/sp again!

The story is like this:
1889: r5/sp of process #1 are saved to u.u_rsav
2189: r5/sp of process #0 are saved! Thus overwriting the values of process #1.
So when we are coming to 2228, how can retu work in a way as it is expected to?

-----------------------------------------------------------------------------

The final question is about how savu/retu work.

savu:
line 0729 and line 0730: r5 and sp are saved to (r0) and (r0)+, which
are the address of u.u_rsav.

retu:
0746 and 0747: sp and r5 are read from (r0) and (r0)+, which is
"rp->p_addr" (see line 2228). It looks weird to me. (Okay...I have to
confess I look stupid here...) When making call to retu, why bother
"retu(rp->p_addr)"? Why not calling with "retu(u.u_rsav)"? Does it
mean that rp->p_addr == u.u_rsav?

OMG, I am totally confused...

--------------------------------------------------------------------------------

I guess It's kind of boring to read my question...but hopefully
someone can give me some hint...Thanks in advance!

Regards,

Qinglai

[TUHS] Reading UNIX V6: Does eash process has its own user structure, or all the processes share one copy of it?

[Hellwig Geisse]

On Tue, 2006-10-03 at 12:05 +0300, jigsaw wrote:
> First, I doubt whether all processes share one "u" or each process has
> its own "u".

Every process has its own u-area.
They have all at the same virtual kernel address,
but live in different physical locations.

> So isn't it saying that there's only one "u" in the core memory?

No. The running process' u-area is mapped into
the virtual address space before executing any
instructions of the process.

Hellwig

[TUHS] Reading UNIX V6: Does eash process has its own user structure, or all the processes share one copy of it?

[jigsaw]

hi Hellwig,

Thank you. Now the first 2 questions are cleared.

I guess the answer to 3rd question is buried in m40.s.....I will check it out.

Thanks again.

Regards,

Qinglai

On 10/3/06, Hellwig Geisse <Hellwig.Geisse at mni.fh-giessen.de> wrote:
> On Tue, 2006-10-03 at 12:05 +0300, jigsaw wrote:
> > First, I doubt whether all processes share one "u" or each process has
> > its own "u".
>
> Every process has its own u-area.
> They have all at the same virtual kernel address,
> but live in different physical locations.
>
> > So isn't it saying that there's only one "u" in the core memory?
>
> No. The running process' u-area is mapped into
> the virtual address space before executing any
> instructions of the process.
>
> Hellwig
>
>

[TUHS] Reading UNIX V6: Does eash process has its own user

[jigsaw]

hi Brantley,

Now I start to understand what's going on.

But do you mean 0744 by 0743?
0743    mov    (sp), r0
0744    mov    $_u, r0

And 2230 should be 2229, which is:
2229    sureg();

Thanks  &
Regards,

Qinglai

On 10/3/06, Brantley Coile <brantley at coraid.com> wrote:
> Rp->p_addr is the address of the swappable image in core.  The process
> image begins with the user segment for that process.  Line 0743 maps
> the upage into the current address space (KISA6) and _retu loads
> previously saved sp and r5 from there.  Notice that on line 2230
> Ken reloads the other memory mapping registers.
>
> Read the section `Memory Management' starting on page 2-4 for background
> on this.
>
>
> U.u_rsave is just a constant location in memory.  Notice that rp->p_addr
> isn't a byte address but a core click address in units of 64 bytes.
>
> Hope that helps.
>
>  Brantley
>
> > The final question is about how savu/retu work.
> >
> > savu:
> > line 0729 and line 0730: r5 and sp are saved to (r0) and (r0)+, which
> > are the address of u.u_rsav.
> >
> > retu:
> > 0746 and 0747: sp and r5 are read from (r0) and (r0)+, which is
> > "rp->p_addr" (see line 2228). It looks weird to me. (Okay...I have to
> > confess I look stupid here...) When making call to retu, why bother
> > "retu(rp->p_addr)"? Why not calling with "retu(u.u_rsav)"? Does it
> > mean that rp->p_addr == u.u_rsav?
>
>

[TUHS] Reading UNIX V6: Does eash process has its own user

[Brantley Coile]

I'm reading from the printed Lion's commentary and I have the 
following:

0742	mov	(sp)+, r1
0743	mov	(sp),KISA6
0744	mov	$_u,r0

What are you looking at?

> hi Brantley,
> 
> Now I start to understand what's going on.
> 
> But do you mean 0744 by 0743?
> 0743    mov    (sp), r0
> 0744    mov    $_u, r0
> 
> And 2230 should be 2229, which is:
> 2229    sureg();
> 
> Thanks  &
> Regards,
> 
> Qinglai
> 
> On 10/3/06, Brantley Coile <brantley at coraid.com> wrote:
>> Rp->p_addr is the address of the swappable image in core.  The process
>> image begins with the user segment for that process.  Line 0743 maps
>> the upage into the current address space (KISA6) and _retu loads
>> previously saved sp and r5 from there.  Notice that on line 2230
>> Ken reloads the other memory mapping registers.
>>
>> Read the section `Memory Management' starting on page 2-4 for background
>> on this.
>>
>>
>> U.u_rsave is just a constant location in memory.  Notice that rp->p_addr
>> isn't a byte address but a core click address in units of 64 bytes.
>>
>> Hope that helps.
>>
>>  Brantley
>>
>> > The final question is about how savu/retu work.
>> >
>> > savu:
>> > line 0729 and line 0730: r5 and sp are saved to (r0) and (r0)+, which
>> > are the address of u.u_rsav.
>> >
>> > retu:
>> > 0746 and 0747: sp and r5 are read from (r0) and (r0)+, which is
>> > "rp->p_addr" (see line 2228). It looks weird to me. (Okay...I have to
>> > confess I look stupid here...) When making call to retu, why bother
>> > "retu(rp->p_addr)"? Why not calling with "retu(u.u_rsav)"? Does it
>> > mean that rp->p_addr == u.u_rsav?
>>
>>

[TUHS] Reading UNIX V6: Does eash process has its own user structure, or all the processes share one copy of it?

[jigsaw]

hi Wolfgang,

Great lecture! I will read other scripts, too.

Thanks &
Regards,

Qinglai

On 10/3/06, Wolfgang Helbig <helbig at lehre.ba-stuttgart.de> wrote:
> Hi,
> at
>         http://www.ba-stuttgart.de/~helbig/os/script/chapt2.2
> I tried to explain the dynamic memory allocation in Unix V6.
>
> Greetings,
> Wolfgang
> --
> "Dijkstra is right, but you don't say such things!"
> (A less courageous programmer)
>
>

[TUHS] Reading UNIX V6: Does eash process has its own user structure, or all the processes share one copy of it?

[Wolfgang Helbig]

Hi,
at
	http://www.ba-stuttgart.de/~helbig/os/script/chapt2.2
I tried to explain the dynamic memory allocation in Unix V6.

Greetings,
Wolfgang
--
"Dijkstra is right, but you don't say such things!"
(A less courageous programmer)