This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Doing more inside an ifunc (Was Re: Document use of IFUNC support outside of libc.)
- From: Siddhesh Poyarekar <sid at reserved-bit dot com>
- To: pinskia at gmail dot com
- Cc: Szabolcs Nagy <szabolcs dot nagy at arm dot com>, Carlos O'Donell <carlos at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>, nd at arm dot com, Ramana Radhakrishnan <Ramana dot Radhakrishnan at arm dot com>, Marcus Shawcroft <Marcus dot Shawcroft at arm dot com>
- Date: Sat, 16 Apr 2016 23:08:54 +0530
- Subject: Re: Doing more inside an ifunc (Was Re: Document use of IFUNC support outside of libc.)
- Authentication-results: sourceware.org; auth=none
- References: <56D8A849 dot 1020109 at redhat dot com> <56D9CBCB dot 2060207 at arm dot com> <56DA02C5 dot 7030208 at redhat dot com> <56DDBB64 dot 9050800 at arm dot com> <20160415151020 dot GA4831 at devel dot intra dot reserved-bit dot com> <BF58C57C-C232-46C6-8677-48E69E72B4BA at gmail dot com>
On Fri, Apr 15, 2016 at 03:09:38PM -0700, pinskia@gmail.com wrote:
> I gave an alternative to this approach by passing midr via the aux
> vector. It still is useful and we can change the kernel to have it
> return unknown for those known values which will be used for
> big.little. I don't have a link to my implementation right now
> though as I am traveling. This is much safer and easier to the
> black listing inside the kernel and the aux vector is basically free
> no open/read/close from ifunc or early launch either.
Is this[1] the patch you're referring to? It seems reasonable to me
given that we can never support big.little reliably with hotplug
potentially mixing things up. But it really depends on how seriously
we want to consider the possibility of having optimal routines for
big.little systems.
We could probably make this patch play nicely with Suzuki's patchset
and use the auxvec entry as a first check and then fall back to
trawling sysfs or do the vdso function call if we ever need to
implement optimal routines for a big.little system. However if
optimizing for big.little is a serious possibility then it makes sense
to solve that problem right now instead of burying it temporarily.
Siddhesh
[1] https://patches.linaro.org/patch/52856/