On Wed, 2 Sep 2015, Pinski, Andrew wrote:

quoted

On Sep 3, 2015, at 1:12 AM, Catalin Marinas [off-list ref] wrote:

quoted

On Wed, Sep 02, 2015 at 10:52:05PM +0800, Andrew Pinski wrote:
That is not a bad idea.  Put this array in the data section of the
VDSO too.  It should be small enough though on systems with 96 or more
cores (dual socket ThunderX has 96 cores total), it is slightly
getting big.
The struct would be something like:
struct
{
 int32 numcores;
 int32 midr[];
};

First of all, I'm against hard-coding (VDSO) data as ABI. So far we used
VDSO to override some weak glibc functions but the VDSO-specific data is
parsed by the VDSO function implementation and not directly by glibc (or
user space). I prefer helper functions that read the VDSO-internal data
structures.

You don't like the idea of a fixed structure ABI that resides inside
vdso data? Having a fixed struct ABI should be ok.  The location
inside the data part was going to be passed via an aux vector entry.
Userland does even need to know it is really located in the vdso at
all. It just happens to reside in there. The data structure would be
well defined for the aux vector.

Restrict the VDSO ABI to well defined single purpose functions. It's
way harder to define data struct ABIs right from the beginning.

Thanks,

	tglx