From: Jaswinder Singh Rajput <jaswinder@kernel.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Ingo Molnar <mingo@elte.hu>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Sam Ravnborg <sam@ravnborg.org>,
Jaswinder Singh Rajput <jaswinderrajput@gmail.com>,
"David S. Miller" <davem@davemloft.net>
Subject: Re: [mingo@elte.hu: [git pull] headers_check fixes]
Date: Wed, 28 Jan 2009 07:06:54 +0530 [thread overview]
Message-ID: <1233106614.3256.6.camel@localhost.localdomain> (raw)
In-Reply-To: <alpine.LFD.2.00.0901271441280.3123@localhost.localdomain>
On Tue, 2009-01-27 at 14:57 -0800, Linus Torvalds wrote:
>
> The thing is, the headers_check stuff is just wrong if it causes these
> things, and I'd rather just turn it off.
>
Basic idea of headers_check is:
1. clean header files so that they do not export useless things in userspace, like:
usr/include/linux/elf-fdpic.h:62: extern's make no sense in userspace
2. provide sufficient stuff like:
usr/include/asm/swab.h:7: found __[us]{8,16,32,64} type without #include <linux/types.h>
3. warns about exporting kernel space defines which are not valid in userspace and is always false for userspace
usr/include/asm/swab.h:10: leaks CONFIG_X86 to userspace where it is not valid
And by headers_check tools we also able to find blunder mistakes which are very difficult to find by naked eye like:
usr/include/asm-generic/fcntl.h:127: leaks CONFIG_64BIT to userspace where it is not valid
for userspace this will be always false.
and some files was totally covered with ifdefs CONFIG_* and exported which are useless like:
usr/include/linux/if_frad.h:29: leaks CONFIG_DLCI to userspace where it is not valid
> If those
>
> #ifdef CONFIG_XYZ
>
> things result in problems, then we should just make the rule be that we
> turn that kind of string into
>
> #if 0
>
This will looks ugly in userspace with so many #if 0 and make impossible
to read the code.
> automatically when exporting the kernel headers. IOW, just about
> _anything_ that headers_check complains about automatically is something
> that should just be _fixed_ automatically at header install time rather
> than make the code harder to read.
>
> So I think it makes our headers worse. Code like
>
> > +#ifdef __KERNEL__
> > +# ifdef CONFIG_X86_BSWAP
> > +# define __X86_BSWAP
> > +# endif /* CONFIG_X86_BSWAP */
> > +#endif /* __KERNEL__ */
>
> just doesn't make sense. It doesn't make sense _inside_ the kernel, and it
> doesn't make sense _outside_ it either.
>
my earlier patch was like this:
diff --git a/arch/x86/include/asm/swab.h b/arch/x86/include/asm/swab.h
index 306d417..613be68 100644
--- a/arch/x86/include/asm/swab.h
+++ b/arch/x86/include/asm/swab.h
@@ -1,12 +1,15 @@
#ifndef _ASM_X86_SWAB_H
#define _ASM_X86_SWAB_H
-#include <asm/types.h>
+#include <linux/types.h>
+#ifdef __KERNEL__
#include <linux/compiler.h>
+#endif /* __KERNEL__ */
static inline __attribute_const__ __u32 __arch_swab32(__u32 val)
{
#ifdef __i386__
+#ifdef __KERNEL__
# ifdef CONFIG_X86_BSWAP
asm("bswap %0" : "=r" (val) : "0" (val));
# else
@@ -16,7 +19,13 @@ static inline __attribute_const__ __u32
__arch_swab32(__u32 val)
: "=q" (val)
: "0" (val));
# endif
-
+#else /* __KERNEL__ */
+ asm("xchgb %b0,%h0\n\t" /* swap lower bytes */
+ "rorl $16,%0\n\t" /* swap words */
+ "xchgb %b0,%h0" /* swap higher bytes */
+ : "=q" (val)
+ : "0" (val));
+#endif /* __KERNEL__ */
#else /* __i386__ */
asm("bswapl %0"
: "=r" (val)
@@ -37,6 +46,7 @@ static inline __attribute_const__ __u64
__arch_swab64(__u64 val)
__u64 u;
} v;
v.u = val;
+#ifdef __KERNEL__
# ifdef CONFIG_X86_BSWAP
asm("bswapl %0 ; bswapl %1 ; xchgl %0,%1"
: "=r" (v.s.a), "=r" (v.s.b)
@@ -48,6 +58,13 @@ static inline __attribute_const__ __u64
__arch_swab64(__u64 val)
: "=r" (v.s.a), "=r" (v.s.b)
: "0" (v.s.a), "1" (v.s.b));
# endif
+#else /* __KERNEL__ */
+ v.s.a = __arch_swab32(v.s.a);
+ v.s.b = __arch_swab32(v.s.b);
+ asm("xchgl %0,%1"
+ : "=r" (v.s.a), "=r" (v.s.b)
+ : "0" (v.s.a), "1" (v.s.b));
+#endif /* __KERNEL__ */
return v.u;
#else /* __i386__ */
asm("bswapq %0"
to get rid of multiple blocks so I used above technique.
If we do not want to export __arch_swab32 and __arch_swab64 then we can
put whole block in #ifdef __KERNEL__ then we will get rid of above
solution.
--
JSR
next prev parent reply other threads:[~2009-01-28 1:38 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20090127222825.GA27097@elte.hu>
2009-01-27 22:57 ` [mingo@elte.hu: [git pull] headers_check fixes] Linus Torvalds
2009-01-27 23:22 ` H. Peter Anvin
2009-01-27 23:29 ` Linus Torvalds
2009-01-28 0:12 ` H. Peter Anvin
2009-01-28 0:19 ` Linus Torvalds
2009-01-28 1:02 ` H. Peter Anvin
2009-01-27 23:31 ` Ingo Molnar
2009-01-27 23:43 ` Linus Torvalds
2009-01-27 23:51 ` Vegard Nossum
2009-01-30 14:01 ` Jaswinder Singh Rajput
2009-01-30 18:20 ` Ingo Molnar
2009-01-28 0:03 ` Harvey Harrison
2009-01-28 1:36 ` Jaswinder Singh Rajput [this message]
2009-01-28 12:37 ` Arnd Bergmann
2009-01-28 17:48 ` H. Peter Anvin
2009-01-28 19:22 ` Harvey Harrison
2009-01-28 19:44 ` Linus Torvalds
2009-01-28 20:03 ` Harvey Harrison
2009-01-28 21:25 ` H. Peter Anvin
2009-01-28 21:58 ` [PATCH] x86: do not expose CONFIG_BSWAP to userspace Harvey Harrison
2009-01-28 22:13 ` Linus Torvalds
2009-01-28 22:40 ` Harvey Harrison
2009-01-30 20:37 ` Pavel Machek
2009-01-28 22:15 ` H. Peter Anvin
2009-01-28 22:38 ` Harvey Harrison
2009-01-28 23:04 ` Ben Pfaff
2009-01-30 18:20 ` H. Peter Anvin
2009-01-28 23:27 ` H. Peter Anvin
2009-01-28 23:36 ` Harvey Harrison
2009-01-28 23:47 ` H. Peter Anvin
2009-02-03 18:19 ` Arnd Bergmann
2009-01-31 18:43 ` Maciej W. Rozycki
2009-01-31 20:24 ` H. Peter Anvin
2009-01-28 23:24 ` Arnd Bergmann
2009-01-28 23:30 ` H. Peter Anvin
2009-01-28 20:49 ` [mingo@elte.hu: [git pull] headers_check fixes] Sam Ravnborg
2009-01-28 21:23 ` H. Peter Anvin
2009-01-28 21:06 ` Sam Ravnborg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1233106614.3256.6.camel@localhost.localdomain \
--to=jaswinder@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=davem@davemloft.net \
--cc=jaswinderrajput@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=sam@ravnborg.org \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox