Re: ppc/ppc64 and x86 vsyscalls

[Benjamin Herrenschmidt]

> This is no reason for not using the DSO form.  The userlevel code finds
> the vDSO via the auxiliary vector.  By passing up different values for
> 32 and 64 bit processes you easily handle the last problem.
> 
> Many functions are no real issue either.  It not inefficient to use the
> symbol table.

Thanks for the clue.

> The only issue is that the vDSO should (IMO must) be position
> independent.  You certainly want to map the same copy in each address
> space.  This means the symbol table cannot contain addresses, only offsets.

Ok. The problem is building the DSO in the kernel from the various
individual functions depending on the CPU & app mode.

> .../...
>
> Why lack?  As a real DSO the vDSO can use the normal unwind info
> handling userlevel DSOs use, too.  I do not see a reason which this
> cannot work.  The unwind info for DSOs is position-independent so it
> should work just fine.

Ok. So the challenge is to write the necessary code in the kernel
to build that DSO based on the various functions after detection
of the CPU type.

Another option would be to pre-build a bunch of them at kernel compile
time. I have to investigate. The risk is that we end up with too
many combinations, thus bloating the kernel image.

Ben.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/