Re: my view about schedule( ) and system call , right or wrong ?

[linux-os (Dick Johnson)]

On Fri, 26 Aug 2005, lab liscs wrote:

> schedule( ) always runs in kernel space, therefore  the address of all
> elements used by schedule() is not virtual address but physical
> address.?


Wrong. All addresses accessed by the CPU(s) are virtual. All addresses
accessed by other devices, including DMA-masters are bus addresses, i.e.,
what a logic analyzer would see. In some architectures, the bus address is
the physical address but in others there is a separate address-space
for devices.

>
>
> analogous question also appears in system call , when I define myself
> syscall , for example:
>
> asmlinkage long sys_check(a,b ,c){
>
>        unsigned long buf;
>
>        ...........
> }
>
> then , the buf is stored in kernel space , that is , physical address .
>
>
> right or wrong
> -

Wrong. 'buf' is stored somewhere on the stack. That stack and its
data can be anywhere in physical memory. It is possible to find
it by searching through page-tables, but what you find will be
the bus address. Since the CPU deals only with virtual addresses,
i.e., translated addresses, that information is not normally useful.

Each user making a system call has a different stack that is
allocated for the purpose of making that system call. The user
can't make the system call on the user's stack because the user
could trash that and bring down the system.

Cheers,
Dick Johnson
Penguin : Linux version 2.6.12.5 on an i686 machine (5537.79 BogoMips).
Warning : 98.36% of all statistics are fiction.
.
I apologize for the following. I tried to kill it with the above dot :

****************************************************************
The information transmitted in this message is confidential and may be privileged.  Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited.  If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@xxxxxxxxxxxx - and destroy all copies of this information, including any attachments, without reading or disclosing them.

Thank you.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/