> On Thu, Sep 03, 1998 at 04:58:02PM +0200, Joerg Pommnitz wrote:
> >
> > Probably not. In this case all you would effectively do
> > is change the syscall interface from:
> >
> > move parameters into registers
> > int 0x80
> >
> > to
> > move parameters into registers
> > jump to kernel entry instruction
> > execute int 0x80 or sysenter
> >
> > I don't have hard numbers, but it looks much slower to me,
> > even if the new kernel entry instruction is a few cycles faster
> > than int 0x80.
> >
> > If something like this is implemented at all, it should
> > be done in libc. glibc already has mechanisms in place to select
> > CPU type optimized code at run time. It would probably be easy to
> > use the same thing for system calls.
> >
>
[SNIPPED]
When you are in user-mode in an ix86, there is no such thing as a
"jump" to the kernel. You either "trap" to the kernel, you execute a
call through a call-gate, or you load a TSS to execute a task-switch to
kernel-mode code.
In any event, your task ceases to exist when the kernel executes. If it
were not for "features" provided by the kernel such as items that persist
(files, pipes, shared memory, etc), isolation between the kernel and user-
mode tasks is perfect because they don't exist at the same time.
The kernel executes functions on behalf of user-mode tasks. How you get
this to happen is dependent upon the system architecture. Linus chose
to execute interrupt 80 hex (which was used by BASIC in MS-DOS).
Since an interrupt is a privileged instruction, when it occurs in
user-mode code, a trap occurs. Kernel software, pointed to by the
IDT handling 80 hex, analyzes the user-mode requests and performs
them on behalf of the user-code code. The nature of the interrupt
handling code allows the interrupted task to be restarted since
the context of the interrupted task is saved.
You need not issue an interrupt to get the attention of the kernel.
User-mode code could execute any privileged instruction. For instance,
the runtime library could execute the CLI instruction. This would
trap to the #GP(0) (General Protection) handler in the kernel at which
time the kernel could analyze the user-mode request. This is certainly
not what #GP(0) was provided for, but it could work.
Using a TSS from user-mode, i.e., LTR will not directly load the
TSS because LTR is also a privileged instruction. It will also
trap at a #GP(0) unless the TSS is not present. In that case
a page-fault trap occurs. In any event, such a TSS should
never be accessible from user-mode or else one could deliberately
damage the OS. It would have to be faulted-in so the kernel could
supply the real one, not one trashed from user-mode code.
A CALL from user-mode code to kernel-mode code requires a call-gate
that is accessible from user-mode code. If this is directly accessible,
it could be corrupted either intentionally or accidentally by
a user-mode pointer. Therefore, it would have to exist either
in a non-writable page or be faulted in by the kernel when an
access is made.
These extra "indirection" steps may actually slow the request for
kernel services although this is not necessarily so because, for
instance, a page-fault has been optimized to be very fast since
it commonly occurs.
Any time saved in executing kernel function calls by executing
code in "strange" ways may be lost as soon as a kernel function
needs to access something provided by user-mode code such as
a pointer to a buffer or even a register value itself. It's
the total time that counts, not the time to make the transition
from user-mode to the kernel.
There is work being done on a new "SysCall" method. Time will
tell if it is really faster. My guess is that it will be 6 of
one-kind and 1/2 dozen of another. Personally I prefer a
software interrupt because it seems as though this is what
the ix86 CPUs were designed to use.
Cheers,
Dick Johnson
***** FILE SYSTEM WAS MODIFIED *****
Penguin : Linux version 2.1.118 on an i586 machine (66.15 BogoMips).
Warning : It's hard to remain at the trailing edge of technology.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html