On Tue, Mar 6, 2018 at 4:48 AM, Christian Borntraeger borntraeger@de.ibm.com wrote:
On 03/06/2018 01:46 PM, Arnd Bergmann wrote:
On Mon, Mar 5, 2018 at 10:30 AM, Christian Borntraeger borntraeger@de.ibm.com wrote:
On 01/16/2018 03:18 AM, Deepa Dinamani wrote:
All the current architecture specific defines for these are the same. Refactor these common defines to a common header file.
The new common linux/compat_time.h is also useful as it will eventually be used to hold all the defines that are needed for compat time types that support non y2038 safe types. New architectures need not have to define these new types as they will only use new y2038 safe syscalls. This file can be deleted after y2038 when we stop supporting non y2038 safe syscalls.
You are now include a <linux/*.h> from several asm files ( arch/arm64/include/asm/stat.h arch/s390/include/asm/elf.h arch/x86/include/asm/ftrace.h arch/x86/include/asm/sys_ia32.h ) It works, and it is done in many places, but it looks somewhat weird. Would it make sense to have an asm-generic/compate-time.h instead? Asking for opinions here.
I don't think we have such a rule. If a header file is common to all architectures (i.e. no architecture uses a different implementation), it should be in include/linux rather than include/asm-generic, regardless of whether it can be used by assembler files or not.
--- a/drivers/s390/net/qeth_core_main.c +++ b/drivers/s390/net/qeth_core_main.c @@ -32,7 +32,7 @@ #include <asm/chpid.h> #include <asm/io.h> #include <asm/sysinfo.h> -#include <asm/compat.h> +#include <linux/compat.h> #include <asm/diag.h> #include <asm/cio.h> #include <asm/ccwdev.h>
Can you move that into the other includes (where all the other <linux/*> includes are.
Good catch, this is definitely a rule we have ;-)
FWIW, this was also broken for arch/x86/include/asm/sys_ia32.h
The reason that this was done this way is because of the sed script mentioned in the commit text. I was trying to make minimal change apart from the script so that we don't have other changes like moving the lines to keep the patch simpler. I will fix this by hand since this is preferred. I will post an update.
-Deepa