Task data
Task data
Where could one keep a pointer the the task structure, so that it can be accessed (in ring 0) to identify the current task? Is there some "hidden" register or something that I could use?
- piranha
- Member
- Posts: 1391
- Joined: Thu Dec 21, 2006 7:42 pm
- Location: Unknown. Momentum is pretty certain, however.
- Contact:
Re: Task data
Well, you'd have to store each task's info in a structure or something, so just have a pointer in the kernel that gets updated to whatever the current task is on each schedule() call.
Like, struct task_data *current_task. And each time schedule is called, you just update the pointer.
-JL
Like, struct task_data *current_task. And each time schedule is called, you just update the pointer.
-JL
SeaOS: Adding VT-x, networking, and ARM support
dbittman on IRC, @danielbittman on twitter
https://dbittman.github.io
dbittman on IRC, @danielbittman on twitter
https://dbittman.github.io
Re: Task data
For my kernel, I store the process list in kernel heap, which is used by the scheduler and process creation/cleanup.
On the other hand, the process header (much like the idea of program segment prefix in DOS), which store per-process data like resource handles, are stored at fixed address on user space.
On the other hand, the process header (much like the idea of program segment prefix in DOS), which store per-process data like resource handles, are stored at fixed address on user space.
Re: Task data
Often one has an entry in the GDT that points to variables that pertain to the CPU, including the current task pointer. This entry is then loaded into FS or GS at the start of every exception handler. Another method would be to have a global TLB mapping that points to these variables.Where could one keep a pointer the the task structure, so that it can be accessed (in ring 0) to identify the current task? Is there some "hidden" register or something that I could use?
Here's something I came up with to easily access such variables from C++ (Visual Studio only), which might be found useful. It assumes that FS points to a a structure named ProcessorVars, and that it contains a field named Self, which points to the same structure. The macro CPUVar(fieldname) can then be used to refer to these fields. Although I'm sure this could probably be done better.
Code: Select all
class FSVar;
template<class T,class U> class StructVar {
public:
DWORD ofs;
StructVar(U T::*x) {ofs=(unsigned long)&(((T*)0)->*x);}
};
template<class T,class U,class V> class CustomVar;
template<class V,class T,class U>
inline CustomVar<T,U,V> GetCustomVar(U T::*x)
{
return CustomVar<T,U,V>(x);
}
template<class T,class U> class CustomVar<T,U,FSVar> : StructVar<T,U> {
public:
CustomVar<T,U,FSVar>(U T::*x) : StructVar<T,U>(x) {}
operator const U() const {
if(sizeof U==4) return (U)__readfsdword(ofs);
if(sizeof U==2) return (U)__readfsword(ofs);
if(sizeof U==1) return (U)__readfsbyte(ofs);
U res;
memcpy(&res,&CPUVar(Self),sizeof U);
return res;
}
U operator=(U x)
{
if(sizeof U==4) __writefsdword(ofs,(DWORD)x);
else if(sizeof U==2) __writefsword(ofs,(WORD)x);
else if(sizeof U==1) __writefsbyte(ofs,(BYTE)x);
else memcpy(&CPUVar(Self),&x,sizeof U);
return U;
}
U operator->() const { return*this; }
};
#define CPUVar(x) GetCustomVar<FSVar>(&ProcessorVars::x)
Re: Task data
I have not think about MP yet (building UP kernel is already so complex for me)Often one has an entry in the GDT that points to variables that pertain to the CPU
But can we use paging to do this? A memory address region that is mapped differently on different CPU, which store the CPU identifier and per-CPU variables. And we setup the pages upon processors initialization in a logic similar to how we create process.
Re: Task data
TSS.SP0. I have thread structure at the top of kernel stack for this thread. It's easy to use.TylerH wrote:Where could one keep a pointer the the task structure, so that it can be accessed (in ring 0) to identify the current task? Is there some "hidden" register or something that I could use?
If you have seen bad English in my words, tell me what's wrong, please.