parameter passing

[Ozguxxx]

My problem is still in passing parameters to kernel from user system calls. I have separated user and kernel address spaces so I cannot pass parameters from a user space to kernel space, my actual problem is in pointers in user space, since I do not map user space into kernel space, I will have to copy each parameter and set stack and then make a system call. But the problem is that I cannot really deal with this since it creates lots of complexity, I mean I will have to copy memory from user space to kernel space and etc. I have come up with a solution, I will load everything onto standard library, it will do all user side memory manipulations and pass parameters all by value. For instance for:

Code: Select all

printf("%s", a_string);

call I will parse a_string char by char in standard library and call kernel to show each character so that I wont have to deal with memory problems, currently I think if I do user memory manipulations in user side, I wont have any problem about parameter passing in the future. What do you think about this approach? I think this is not the usual way of handling system calls. I want to keep as simple as possible for now. Thanx in advance.

[Tim]

The normal way is to map the kernel into each address space. That way you're always guaranteed to be able to access any part of the kernel regardless of which process is currently active, and you're always able to manipulate the memory of the current process.

[OS]

reserve a special virtual memory area per process ( or per thread ) ( for example between 0x10000000 - 0x10000FFF ) that will be used to pass large amounts of data to the kernel or vice versa...

[Pype.Clicker]

when you say you have "separated kernel and user space", do you mean you actually have one address space for the kernel and one for the user process ?

What is your goal when doing this ? How could the kernel (for instance) prepare more pages for the user application ?

And i doubt you can pass strings 'by value' between kernel and user since it usually requires you to pass arguments through registers ...

As "OS" suggested, if you really need this separation to take place, consider keeping a shared area between the kernel and each user process so that it can still be communication between the two (it may be up to the stdlib to place arguments at that place if you really wish so). And if you can afford it, consider having the kernel present in every user process ...

[distantvoices]

I s'pose mapping kernel land into each process adress space. This eases Life and leads to a simple and straight forward design. Mark: the kernel land is the sort of shared memory that feases IPC, IO-Streams and Pipes between processes.

Your approach, Ozgun, would lead to an immense and ugly complexity which doesn't need to spring into existence. Best get rid of it and keep it simple.

I for my part vote for: Kernel land mapped into each process adress space.

[Solar]

I'm not sure I got the concept right, Ozgunh82, but for your user space to call prinf(), you have to have a stub function printf() in user space that actually does the call to kernel space, right?

So, either you do the kernel-space mapping as suggested, or you craft those stub functions in a way that they package all required data and send it to the kernel as a message...

[distantvoices]

He'd need to pipe the dayta to the kernel and that's something I call ugly, for the kernel can, if mapped in the process' adress space, simply retrieve the data from it 's location in user land - just by reading it. It is as simple as tossing forth a pointer (throu' a smal message or a parameter struct or a register ...)

[Ozguxxx]

I cannot understand something about the interrupt handling mechanism, if a user and kernel page directories are different, then when an interrupt occurs, cpu does not load kernel pdbr while handling interrupt, assuming that a a task switch does not occur, I mean cpu ONLY reloads stack pointer by looking at tss of user process, right?

[distantvoices]

nay.

Listen: you issue an interrupt: the cpu traps into kernel space, saves off eip, cs,eflags,ss,esp. Then it switches to the ss0 and esp0 indicated in the system tss. This involves no page directory switching. You decide at schedule/task picking time - in a function that picks the next runnable process/thread - whether to switch page directory or not.

If you have an own page directory for your kernel space and each process has its own page directory - without kernel space mapped into it (as i'm assuming by the sounds of your inquiry) - issuing an interrupt would cause the system to triple fault - it canna find the IDT. It canna find the kernel.

This is roughly spoken. The sophisticated ones amongst us would bash me for this. *dodging away*

[Solar]

$ /bin/bash beyond_infinity

;D

[distantvoices]

*ouch*aw*wham*

... segmentation fault at 0x15ab ...

*rofl*

[Pype.Clicker]

actually, the only way to 'trap' to kernel if kernel is not in the user process's address space is to use a task gate in the IDT. However, this means that:
* no registers can be use to pass information as the kernel task will recover its registers from the TSS
* the kernel may not interrupt its operation on behalf of process A and give access to process B as the process B will try to use the *same* TSS and resources if it issues a kernel trap
* a dedicated 'communication' needs to be set up between each user process and the 'kernel' process in order to receive parameters and return values

Nah. Really, this is BadIdea (tm by Bug'0's0ft) ...

Keep your kernel as a part of every address space (e.g. each process has its own directory *but* the N first/last tables of that directory are the same for every process and contains the kernel. user process cannot alter those pages because they'll be set at supervisor level).

[Ozguxxx]

So this means that you cannot handle interrupts if kernel is not mapped into user address spacei -if handlers are all in kernel level-, well in fact I am mapping kernel address space into user address space but the problem is that I was continuously assuming that cpu loaded kernel cr3 when and interrupt is handled in user address space, but the in reality, while an interrupt that occurs while a user process is executing is handled inside user address space, right? I mean user cr3 is used to do page translations but since kernel is mapped exactly into its own address space the interrupt is handled correctly. So this means that if I simply passed the pointers in user address space to kernel in system calls, I wont have any problems as long as I map kernel into user. As a result there is no problem left... I think I will have to think more things before asking questions...

[distantvoices]

I've solved the part of understanding the process adress space concept and where to put the kernel by taking a piece of paper and a pen and drawing some sketches of things I saw with my inner eye. A picture makes things clearer than dozens of words could do.

Actually I 've needed more than one sheet of paper and a lot of scratching the head ere I've got it right. *gg*

[Pype.Clicker]

??? i'm glad if there isn't problems anymore, but i must admit i'm completely confused by your last post and couldn't sketch at all what is in your mind ...

$> cat ozgunh:/dev/brain
permission denied

doh.