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  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]
Date:	Sat, 19 Jul 2014 02:02:22 +0800
From:	Chen Gang <>
To:	Lennox Wu <>
CC:	Richard Weinberger <>, Arnd Bergmann <>,
	Lars-Peter Clausen <>,
	Guenter Roeck <>,
	Greg Kroah-Hartman <>,
	Dmitry Torokhov <>,,
	Benjamin Herrenschmidt <>,
	Tom Gundersen <>,
	Thierry Reding <>,
	Marek Vasut <>,
	Liqin Chen <>,,,,,,
	"" <>,, Martin Schwidefsky <>,,,
	Geert Uytterhoeven <>
Subject: Re: [PATCH] drivers: Let several drivers depends on HAS_IOMEM for

On 07/18/2014 11:37 PM, Lennox Wu wrote:
> Score can provide dummy functions if HAS_IOMEM  and NO_IOMEM will be
> removed, even if we indeed have no IOMEM.

Thank you for your reply, for score, your ideas is OK to me.

And for the COMPILE_TEST needs still discussing below:

> 2014-07-18 18:51 GMT+08:00 Richard Weinberger <>:
>> Am 18.07.2014 12:44, schrieb Chen Gang:
>>> On 07/18/2014 03:35 PM, Richard Weinberger wrote:
>>>> Am 18.07.2014 02:36, schrieb Chen Gang:
>>>>> On 07/18/2014 02:09 AM, Richard Weinberger wrote:
>>>>>> Am 17.07.2014 12:48, schrieb Arnd Bergmann:
>>>>>>> AFAICT, NO_IOMEM only has a real purpose on UML these days. Could we take
>>>>>>> a shortcut here and make COMPILE_TEST depend on !UML? Getting random stuff
>>>>>>> to build on UML seems pointless to me and we special-case it in a number of
>>>>>>> places already.
>>>>>> If UML is the only arch without io memory the dependency on !UML seems
>>>>>> reasonable to me. :-)
>>>>> For me, if only uml left, I suggest to implement dummy functions within
>>>>> uml instead of let CONFIG_UML appear in generic include directory. And
>>>>> then remove all HAS_IOMEM and NO_IOMEM from kernel.
>>>> Erm, this is something completely different.
>>>> I thought we're focusing on COMPILE_TEST?
>>> COMPILE_TEST is none-architecture specific, but UML is. So in generic
>>> include folder, if we're focusing on choosing whether COMPILE_TEST or
>>> UML, for me, I will choose COMPILE_TEST.
>>> If we're not only focusing on COMPILE_TEST, for me, if something only
>>> depend on one architecture, I'd like to put them under "arch/*/" folder.
>>> Especially, after that, we can remove all HAS_IOMEM and NO_IOMEM, nobody
>>> has to think of them again. :-)
>> And then we end up with a solution that on UML a lot of completely useless
>> drivers are build which fail in various interesting manners because you'll
>> add stubs for all kinds of io memory related functions to arch/um/?
>> We had this kind of discussion already. You'll need more than ioremap...
>> I like Arnd's idea *much* more to make COMPILE_TEST depend on !UML.

That will let UML itself against COMPILE_TEST (but all the other
architectures not).

And if let COMPILE_TEST depend on !UML, can we still remove all
HAS_IOMEM and NO_IOMEM from kernel? (I guess so).

If we can remove them, we can send related patch firstly -- that will
let current discussion be in UML architecture wide instead of kernel

Chen Gang

Open share and attitude like air water and life which God blessed
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists