Re: vdso(7): new man page

[Mike Frysinger <vapier-aBrp7R+bbdUdnm+yROfE0A@public.gmane.org>]

[-- Attachment #1: Type: Text/Plain, Size: 2436 bytes --]

On Thursday 11 April 2013 14:31:55 Andy Lutomirski wrote:
> On Tue, Apr 9, 2013 at 8:17 PM, Mike Frysinger <vapier-aBrp7R+bbdUdnm+yROfE0A@public.gmane.org> wrote:
> > so i've slapped this together.  i think the HISTORY section could use
> > more filling out, but that'd probably be more for funsies rather than
> > usefulness.
> 
> This looks good to me.  It may be worth mentioning that programs must
> not assume anything about where the vDSO is mapped -- that may change
> from kernel to kernel or exec to exec, unless the particular
> architecture makes some guarantee.

good idea

> > .SS Example Background
> > Making syscalls themselves can incur significant penalty.
> > In x86 systems, you can trigger a software interrupt (int $0x80) to tell
> > the kernel you wish to make a syscall.
> > Internally, this means the call has to go through the normal interrupt
> > layers to save/restore context before it even gets a chance to start
> > processing the system call.
> > Wouldn't it be nicer if you could start processing the system call
> > immediately? With newer revisions of the x86 architecture, there is now
> > a syscall/sysenter instruction that does exactly that (jumps directly to
> > the system call entry). However, rather than require the C library to
> > figure out if this functionality is available itself, the vDSO includes
> > symbols that can be used. This is typically referred to using the term
> > "vsyscall".
> 
> I find this a bit confusing.  The term "vsyscall" means something
> different on x86_64, and syscall and sysenter are different
> instructions.  How about this:
> 
> Making syscalls can be slow.
> In x86 32-bit systems, you can trigger a software interrupt (int
> $0x80) to tell the
> kernel you wish to make a syscall.  This instruction is expensive: it
> goes through the full interrupt handling paths in microcode and in the
> kernel.  Newer processors have faster, incompatible ways to issue
> system calls, and the kernel abstracts these through an entry point in
> the vdso.  (The terminology can be confusing.  On x86_32, this
> function is called __kernel_vsyscall, but on x86_64, the term
> "vsyscall" refers to an obsolete way to ask the kernel what time it is
> or what cpu the caller is on.)

i've merged in your suggestions.  is the current (small) HISTORY section 
correct then ?  you can find it at the bottom of the page.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]