Date: Sat, 20 Feb 2010 12:57:58 -0800 (PST)
Message-Id: <20100220.125758.174837163.davem@davemloft.net>
To: weigelt@metux.de
Cc: linux-kernel@vger.kernel.org
Subject: Re: Dynamic linking in the kernel
From: David Miller <davem@davemloft.net>
In-Reply-To: <4B802870.5030201@metux.de>
References: <4B802870.5030201@metux.de>
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1421
Lines: 33

From: Enrico Weigelt <weigelt@metux.de>
Date: Sat, 20 Feb 2010 19:22:40 +0100

> Starting up an dynamically linked executable tends to need a lot
> of syscalls. A kernel-based dynamic linker could cache a lot of
> relocation data (eg. when the same binary is called many times),
> share pages even w/o mmap(), and the ldstub wouldnt be needed
> anymore.

This is not practical.

In order to implement this the kernel would have to also save a copy
of all pieces of the processes's environment and compare all of the
environment variable settings on every execution.  This would be
needed to handle things like LD_PRELOAD, LD_LIBRARY_PATH, and LD_DEBUG
as just three examples.

What's more, any filesystem change involved in the shared libraries,
the executable, or the dynamic linker would have to be monitored as
well.

Really, this is not a good idea, and the cost is only ~3 system calls
per shared library and considering the amount of flexibility we get in
return it's not that bad at all.

Actually, the more expensive part of shared libraries are the page
faults from filling in the relocations and we already have a mechanism
to save that cost, it's called 'prelink'.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/