Variable "current" in Linux kernel...

Siva Prasad sprasad at bivio.net
Wed Apr 18 01:12:02 EST 2007


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 at gmail.com] 
Sent: Monday, April 16, 2007 3:53 PM
To: Siva Prasad
Cc: linuxppc-dev at ozlabs.org; linuxppc-embedded at ozlabs.org
Subject: Re: Variable "current" in Linux kernel...

On 4/16/07, Siva Prasad <sprasad at 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



More information about the Linuxppc-embedded mailing list