Doing this one architecture at a time is just me being careful. It is entirely possible that it is all common code and the corresponding change will work everywhere.
I just want to avoid finding out in 6 months about a regression on an architecture I am not able to test on and then trying to figure out some way to disable this on just that architecture. Cheers, Rafael "Joseph Myers" <jos...@codesourcery.com> writes: > On Sun, 2 Dec 2018, Rafael Avila de Espindola wrote: > >> I have enabled static vdso on every architecture I can test it. That is, >> on every architecture in the gcc farm that can build glibc. > > Having such a series of patches for different architectures suggests to me > that there is too much in architecture-specific code, and more of the vDSO > handling should be in architecture-independent code in glibc - in general > in recent years we've been trying to move more things to > architecture-independent code, with a minimum of architecture-specific > overrides where actually needed. > > Could you describe what is common and what is different between > architecture vDSO support in the Linux kernel. For example: > > * Do all architectures support a vDSO at all? > > * Are there functions that are present in the vDSO for all architectures, > or is the set of functions completely architecture-specific? > > * For the syscall interface, we have the asm-generic interface that > defines the preferred set of syscalls that all new architectures will use. > Is there anything like that for the vDSO - a preferred vDSO interface we > know all new Linux kernel architectures will use? If there is, it would > indicate what should be the default in architecture-independent code in > glibc, and what should be considered a deviation needing an > architecture-specific override. > > -- > Joseph S. Myers > jos...@codesourcery.com _______________________________________________ cfarm-users mailing list cfarm-users@lists.tetaneutral.net https://lists.tetaneutral.net/listinfo/cfarm-users
