Variable "current" in Linux kernel...

Variable "current" in Linux kernel...

[Siva Prasad]

[-- Attachment #1: Type: text/plain, Size: 734 bytes --]

Hi,

 

I would like to know where exactly the value of variable "current" gets
changed.

 

Background:

I am trying to get Linux running on 32-bit PowerPC. However, I want to
get that running from address 1GB (0x40000000) as the starting memory,
and not the regular 0x00000000. When I am making this change, I found
that the value of "current" is getting messed up some where. I tried to
search unsuccessfully where it gets set. Appreciate any help.

 

BTW... did any one tried before to run from a different location of
memory than the usual 0x00000000? What are the main problems you faced?
I know this is open ended question, but wanted to see if any one ever
did that.

 

Thanks

Siva

 

 


[-- Attachment #2: Type: text/html, Size: 3354 bytes --]

Re: Variable "current" in Linux kernel...

[Phillip Lougher]

On 4/16/07, Siva Prasad <sprasad@bivio.net> wrote:
>
> I would like to know where exactly the value of variable "current" gets
> changed.

current points to the task_struct structure of the currently running
process.  It, obviously, changes each time the scheduler schedules
another process.

>
>
> BTW=85 did any one tried before to run from a different location of memor=
y
> than the usual 0x00000000? What are the main problems you faced? I know t=
his
> is open ended question, but wanted to see if any one ever did that.
>

I changed the 2.4 PPC kernel to do this about 5 years ago (for
Zarlink).  Most of the issues relate to the PPC specific code, all
functions which map from a va->pa, from a pte->va, and vice-versa have
to be changed.  The early start up assembly code has to be aware the
kernel is not running at zero, specifically the code which creates the
initial TLB entries.  As far as I can recall, only one line of non-PPC
specific code needed to be changed.  It is, however, a difficult task
which requires careful auditing of the code, and obviously  knowledge
of the vm and memory allocator systems.

Phillip

Re: Variable "current" in Linux kernel...

[Andreas Schwab]

"Siva Prasad" <sprasad@bivio.net> writes:

> I would like to know where exactly the value of variable "current" gets
> changed.

In _switch (see arch/powerpc/kernel/entry_{32,64}.S).  For ppc32, current
is always in r2.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

RE: Variable "current" in Linux kernel...

[Siva Prasad]

One question for the community:
Why are we storing the physical address of a task. Why can't we store
the virtual address, and convert it as and when required by using
tophys(). By storing the physical address, are we not loosing this code
portability. May be I am wrong, but would like to understand.

Thanks Phillip.
Now even the bootmem code needs update, as that considers 0x00000000 as
default lower address and does the computations for free memory based on
that.

Thanks every one for the help.

Thanks
Siva



-----Original Message-----
From: Phillip Lougher [mailto:phillip.lougher@gmail.com]=20
Sent: Monday, April 16, 2007 3:53 PM
To: Siva Prasad
Cc: linuxppc-dev@ozlabs.org; linuxppc-embedded@ozlabs.org
Subject: Re: Variable "current" in Linux kernel...

On 4/16/07, Siva Prasad <sprasad@bivio.net> wrote:
>
> I would like to know where exactly the value of variable "current"
gets
> changed.

current points to the task_struct structure of the currently running
process.  It, obviously, changes each time the scheduler schedules
another process.

>
>
> BTW... did any one tried before to run from a different location of
memory
> than the usual 0x00000000? What are the main problems you faced? I
know this
> is open ended question, but wanted to see if any one ever did that.
>

I changed the 2.4 PPC kernel to do this about 5 years ago (for
Zarlink).  Most of the issues relate to the PPC specific code, all
functions which map from a va->pa, from a pte->va, and vice-versa have
to be changed.  The early start up assembly code has to be aware the
kernel is not running at zero, specifically the code which creates the
initial TLB entries.  As far as I can recall, only one line of non-PPC
specific code needed to be changed.  It is, however, a difficult task
which requires careful auditing of the code, and obviously  knowledge
of the vm and memory allocator systems.

Phillip