This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [RFC/PATCH] ARM: VDSO support
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Adhemerval Zanella <adhemerval dot zanella at linaro dot org>
- Cc: <libc-alpha at sourceware dot org>
- Date: Tue, 7 Apr 2015 17:20:59 +0000
- Subject: Re: [RFC/PATCH] ARM: VDSO support
- Authentication-results: sourceware.org; auth=none
- References: <1428081934-22419-1-git-send-email-nathan_lynch at codesourcery dot com> <alpine dot DEB dot 2 dot 10 dot 1504071643550 dot 20250 at digraph dot polyomino dot org dot uk> <55240E78 dot 7020807 at linaro dot org> <alpine dot DEB dot 2 dot 10 dot 1504071714020 dot 20250 at digraph dot polyomino dot org dot uk>
On Tue, 7 Apr 2015, Joseph Myers wrote:
> On Tue, 7 Apr 2015, Adhemerval Zanella wrote:
>
> > On 07-04-2015 13:46, Joseph Myers wrote:
> > > On Fri, 3 Apr 2015, Nathan Lynch wrote:
> > >
> > >> This patch adds support for the ARM VDSO to glibc. I have run make
> > >> check on OMAP5 using kernels with and without the VDSO, with no new
> > >> failures.
> > > How does this compare to the implementations for other architectures?
> > > What are the points on which the VDSO interfaces vary between
> > > architectures? It would seem desirable for the code to be factored so
> > > that the ARM code only contains the minimal set of things that are
> > > necessarily ARM-specific (for example, just declaring the ARM-specific
> > > choices before including architecture-independent files shared by all
> > > architectures that can get these functions from a VDSO).
> > >
> > I see the factoring work being another subsequent patch that should not
> > impede the inclusion of proposed modification.
>
> I see it as a preparatory cleanup that is (unlike the main change) not
> blocked on the kernel changes getting into kernel.org sources.
And, in any case, if a non-refactored patch is to go in, the analysis of
how the implementations and interfaces for different architectures relate
should be part of the justification for the implementation approach
chosen. That is, the questions I posed should be answered as questions,
regardless of what patch the answers end up supporting.
--
Joseph S. Myers
joseph@codesourcery.com