linux-kernel - Re: [PATCH] include/asm-generic/io.h: add dummy fuctions to support 'COMPILE

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <51D4EB7D.2020809@gmail.com>
Date:	Thu, 04 Jul 2013 11:26:53 +0800
From:	Chen Gang F T <chen.gang.flying.transformer@...il.com>
To:	Steven Rostedt <rostedt@...dmis.org>
CC:	Chen Gang <gang.chen@...anux.com>,
	Greg KH <gregkh@...uxfoundation.org>,
	Arnd Bergmann <arnd@...db.de>,
	Geert Uytterhoeven <geert@...ux-m68k.org>,
	Richard Weinberger <richard@....at>,
	Jeff Dike <jdike@...toit.com>,
	David Sharp <dhsharp@...gle.com>,
	"sfr@...b.auug.org.au" <sfr@...b.auug.org.au>,
	Ingo Molnar <mingo@...nel.org>,
	uml-devel <user-mode-linux-devel@...ts.sourceforge.net>,
	uml-user <user-mode-linux-user@...ts.sourceforge.net>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Linux-Arch <linux-arch@...r.kernel.org>,
	Mark Brown <broonie@...nel.org>,
	David Miller <davem@...emloft.net>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Jiri Kosina <trivial@...nel.org>, Jiri Slaby <jslaby@...e.cz>
Subject: Re: [PATCH] include/asm-generic/io.h: add dummy fuctions to support
 'COMPILE_TEST' in 'asm-generic'.

On 07/04/2013 11:06 AM, Steven Rostedt wrote:
> On Thu, 2013-07-04 at 10:42 +0800, Chen Gang F T wrote:
> 
>> > Hmm..., I think maybe also has another way: get rid of 'COMPILE_TEST'
>> > (regress the related patch, which is only existent in next-* tree).
> I'm not working on linux-next at the moment. Hmm, I'm not even working
> on mainline at the moment, the kernel I have is still 3.10-rc5.
> 

OK, thanks. I can understand.

Every contributors have their own focus areas, each area is valuable enough to go deeper and deeper.

>> > 
>> > Or could you provide your suggestions or completions about it ?
>> > 
>> > Thanks.
>> > 
>>> > > I'm still confused by what you are trying to accomplish.
>> > 
>> > Currently, I am trying to compile all architectures with allmodconfig in
>> > next-* tree (which will have "COMPILE_TEST=y").
>> > 
>> > So I can find and solve the related issues (I am one of contributors).
>> > 
> So, you want all archs to pass an allmodconfig?
> 

Yeah, that is my current goal.

By this way, I can find more issues and try to solve them (it will be
good for public kernel), and also I can familiar the compiler step by
step (the cross-compilers also has their issues).

(In fact, I also want randconfig, and has already done for some
architectures). ;-)


> Well, one thing is, if a module doesn't build for an arch, then why not
> keep that module from building for that arch.
> 

Please see the related comment in "init/Kconfig" of next-* tree.

config COMPILE_TEST
       bool "Compile also drivers which will not load"
       default n
       help
         Some drivers can be compiled on a different platform than they are
         intended to be run on. Despite they cannot be loaded there (or even
         when they load they cannot be used due to missing HW support),
         developers still, opposing to distributors, might want to build such
         drivers to compile-test them.

         If you are a developer and want to build everything available, say Y
         here. If you are a user/distributor, say N here to exclude useless
         drivers to be distributed.


> If module foo.ko doesn't build for arch bazinga, then just add in the
> Kconfig for the module foo:
> 
> config FOO
>   depends on !BAZINGA
> 
> Then that module wont build for the specific arch, and all are happy. If
> someone someday wants to support module foo for arch bazinga, then they
> can fix module foo for that arch.

If get rid of 'COMPILE_TEST', what you said above are reasonable.

When one module select "COMPILE_TEST=y", if it can not pass compiling
because of HW not support, it is not the module's issue, at least.

Hmm..., but at least for me, I still think, "COMPILE_TEST=y" is really
useful.


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