Fast vs slow syscalls (Re: Fwd: [RFC] Kernel shared variables)

[Peter Wemm]

On Thu, Jun 7, 2012 at 1:26 AM, Dag-Erling Smørgrav <des at des.no> wrote:
> Bruce Evans <brde at optusnet.com.au> writes:
>> Now 2.44 nsec/call makes sense, but you really should add some volatiles
>> here to ensure that getpid() is not optimized away.
>
> As you can see from the disassembly I provided, it isn't.
>
>> SO it loops OK, but we can't see what getpid() does.  It must not be
>> doing much.
>
> Umm, yes, that's the whole point of this conversation.  Linux's getpid()
> is not a syscall, but a library function that returns a constant from a
> page shared by the kernel.

It might be worth taking a peek at what they do before going too far
down the rabbit hole.  They've had to deal with the whole ABI
stability vs kernel layout thing already.

As I recall, they literally embed a userland style .so shared object
into the kernel and make it available to the user.  The dynamic linker
"finds" it via elf auxinfo and inserts it into the symbol search
order.

That way, the shared page layout is kernel specific.  If they chose to
provide getpid() or gettimeofday() or whatever, its a matter of
adjusting the shared page and inserting code into the .so file.  If
the page changes, the code changes.

Think of what we do with signal trampolines except in a way
ld-elf.so.1 can pull it into user space and gdb "sees" it as a .so
file with debug info.

I think I remember that they did the shared page thing and then
switched to providing a stub .so file.

-- 
Peter Wemm - peter at wemm.org; peter at FreeBSD.org; peter at yahoo-inc.com; KI6FJV
"All of this is for nothing if we don't go to the stars" - JMS/B5
"If Java had true garbage collection, most programs would delete
themselves upon execution." -- Robert Sewell