user-mode-linux-user

[uml-user] self-built root filesystem failed to boot

[Han <kee...@gm...>]

Hi,

I've built a root filesystem based off Debian Squeeze because I wanted to
include all built (e.g. gcc) tools in.  However,  i was not able to boot
the UML with this rootfs due to this error:

<snip>
Kernel panic - not syncing: No init found.  Try passing init= option to
kernel.
</snip>

here is how I ran the UML:

./linux ubda=/nobackup/hxu2/uml/debian-root-fs mem=128M

I also tried to add "init=/sbin/init" or "init=3" at the end, but got the
same error.

I believe I missed something when building the rootfs for the Init option.
But what is it?  How should I set the init option in the rootfs?  please
advise.

thanks
Han

[uml-user] RTC (real time clock) support in UML

[Han <kee...@gm...>]

Hi,

I am using UML in kernel 2.6.27. In the uml kernel I've built,  there is no
"native_read_tsc" symbol. Does UML support RTC ?  Is there a config option
I need to enable?

thanks in advance.

Han

[uml-user] kernel panic when loading a module (klm)

[Han <kee...@gm...>]

Hi,

I am trying to load a kernel module into UML.  I've built the module using
the same source tree that built the UML kernel.  But when I tried to load
(insmod) the module, the kernel panic happened.

The kernel version: 2.6.27

The module init code is trying to create a directory under /proc:

static int __init isan_proc_init(void)
{
    printk("in %s\n", __FUNCTION__);

    proc_test = proc_mkdir("test1", NULL);   // insmod OK if removed this
line

    return 0;
}

The kernel panic does _not_ happen if I removed the call of proc_mkdir.
 But I don't understand why.  Here is the kernel panic log:

#insmod ./klm_procfs_init.klm
in isan_proc_init

EIP: 0023:[<080da984>] CPU: 0 Not tainted ESP: 002b:10a38e78 EFLAGS:
00010206
    Not tainted
EAX: 00004000 EBX: 10893ed0 ECX: 10a38e7c EDX: 08217b28
ESI: 75ff5750 EDI: 08056278 EBP: 10a38e8c DS: 002b ES: 002b
081f8af0:  [<08069b53>] show_regs+0xb4/0xb9
081f8b1c:  [<080591b2>] segv+0x222/0x23a
081f8bbc:  [<0805925a>] segv_handler+0x90/0x9a
081f8c68:  [<08064968>] sig_handler_common+0x63/0x72
081f8ce0:  [<08064c5c>] sig_handler+0x31/0x3d
081f8cec:  [<08064bbb>] handle_signal+0x4c/0x7a
081f8d0c:  [<080662d7>] hard_handler+0xf/0x14
081f8d1c:  [<ffffe500>] _etext+0xf7e68408/0x0

Kernel panic - not syncing: Kernel mode fault at addr 0x75ff5758, ip
0x80da984

EIP: 0023:[<400ed59e>] CPU: 0 Not tainted ESP: 002b:ff507d90 EFLAGS:
00000246
    Not tainted
EAX: ffffffda EBX: 0804b018 ECX: 0000d361 EDX: 0804b008
ESI: 08048760 EDI: 4000e380 EBP: ff507de8 DS: 002b ES: 002b
081f8a5c:  [<08069b53>] show_regs+0xb4/0xb9
081f8a88:  [<08059426>] panic_exit+0x25/0x3b
081f8a9c:  [<080836d6>] notifier_call_chain+0x27/0x4c
081f8ac4:  [<08083712>] __atomic_notifier_call_chain+0x17/0x19
081f8ad4:  [<08083729>] atomic_notifier_call_chain+0x15/0x17
081f8af0:  [<0806fea3>] panic+0x52/0xd8
081f8b10:  [<080591c0>] segv+0x230/0x23a
081f8bbc:  [<0805925a>] segv_handler+0x90/0x9a
081f8c68:  [<08064968>] sig_handler_common+0x63/0x72
081f8ce0:  [<08064c5c>] sig_handler+0x31/0x3d
081f8cec:  [<08064bbb>] handle_signal+0x4c/0x7a
081f8d0c:  [<080662d7>] hard_handler+0xf/0x14
081f8d1c:  [<ffffe500>] _etext+0xf7e68408/0x0

Segmentation fault (core dumped)

And for some reason, the core was not complete:

(gdb) target core core.20687
BFD: Warning: /nobackup/hxu2/uml/linux-2.6.27/core.20687 is truncated:
expected core file size >= 134807552, found: 104960000.

[New Thread 20687]
[New Thread 20695]
[New Thread 20694]
[New Thread 20693]
warning: Can't read pathname for load map: Input/output error.
Cannot access memory at address 0xf7fd30f0
(gdb) bt
#0  0x007a7821 in ?? ()
#1  0x00000006 in ?? ()
#2  0x081f8960 in cpu0_irqstack ()
#3  0x00000000 in ?? ()
(gdb)

What could be possible reason for proc_mkdir to cause kernel panic?

thanks
Han

Re: [uml-user] Patch skas3 - Kernel 2.6.32

[CAQUINEAU, Pierre-A. <pa....@nu...>]

Hi,

 

In my memories, I thought that the skas3 patch increased the performance and
security for VM. That false ?

Why skas0 is better than  skas3 ?

 

 

Sincerely,

P.A.

 

De : Antoine Martin [mailto:an...@na...] 
Envoyé : mardi 23 juillet 2013 06:10
À : use...@li...
Objet : Re: [uml-user] Patch skas3 - Kernel 2.6.32

 

On 23/07/13 00:27, Michael Richardson wrote:

 
1) I don't thikn that skas3 every got ported to 2.6.32.

You can find links to more up to date skas3 patches here:
http://uml.devloop.org.uk/links.html 

2) Why do you want it? skas0 usually does better.

Usually.

Antoine



 
 
--
]               Never tell me the odds!                 | ipv6 mesh networks
[
]   Michael Richardson, Sandelman Software Works        | network architect
[
]     mc...@sa...  http://www.sandelman.ca/        |   ruby on rails
[
 
 
 
 
----------------------------------------------------------------------------
--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831
<http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> &iu=/4140/ostg.clktrk
_______________________________________________
User-mode-linux-user mailing list
Use...@li...
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-user

 

Re: [uml-user] Patch skas3 - Kernel 2.6.32

[Antoine M. <an...@na...>]

On 23/07/13 00:27, Michael Richardson wrote:
> 1) I don't thikn that skas3 every got ported to 2.6.32.
You can find links to more up to date skas3 patches here:
http://uml.devloop.org.uk/links.html
> 2) Why do you want it? skas0 usually does better.
Usually.

Antoine
>
> --
> ]               Never tell me the odds!                 | ipv6 mesh networks [
> ]   Michael Richardson, Sandelman Software Works        | network architect  [
> ]     mc...@sa...  http://www.sandelman.ca/        |   ruby on rails    [
>
>
>
>
> ------------------------------------------------------------------------------
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> _______________________________________________
> User-mode-linux-user mailing list
> Use...@li...
> https://lists.sourceforge.net/lists/listinfo/user-mode-linux-user

Re: [uml-user] Patch skas3 - Kernel 2.6.32

[Michael R. <mc...@sa...>]

1) I don't thikn that skas3 every got ported to 2.6.32.
2) Why do you want it? skas0 usually does better.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     mc...@sa...  http://www.sandelman.ca/        |   ruby on rails    [

[uml-user] Patch skas3 - Kernel 2.6.32

[CAQUINEAU, Pierre-A. <pa....@nu...>]

Hi,

 

Anybody can tell me where I can find the skas3 patch for this kernel :
2.6.32 and if there is a URLs list with all patch ?

 

Sincerely.

Re: [uml-user] [PATCH] include/asm-generic/io.h: add dummy fuctions to support 'COMPILE_TEST' in 'asm-generic'.

[Chen G. F T <che...@gm...>]

Firstly, thank you very much for your reply.

On 07/05/2013 07:13 PM, Arnd Bergmann wrote:
> On Friday 05 July 2013, Chen Gang F T wrote:
>> > Hello All:
>> > 
>> > It seems 'asm-generic' dislikes 'mad users' (e.g allmodconfig,
>> > randconfig, and me).
>> > 
>> > I guess the main reason is: 'asm-generic' thinks what mad users talk
>> > about is useless in real world, so it is just noisy.
>> > 
>> > I can understand, at least what I talk about is not for urgent things.
>> > (maybe 'asm-generic' also thinks it not important either, every members
>> > have their own opinions).
>> > 
>> > Next, I still use allmodconfig/randconfig for some architectures which I
>> > am interested in (and also for learning compilers), but I will skip all
>> > things which are related with 'asm-generic', since it dislikes me (a mad
>> > user).
> As the asm-generic maintainer I think I have to clarify a few things:
> 
> * Build-time fixes for warnings and randconfig errors are good,
>   and you have sent a number of good bug fixes all over the kernel,
>   I definitely welcome getting more of those. In many cases the
>   fix is trivial and obvious, in other cases you need to know
>   much more of the background to understand what the underlying
>   problem is and why you should not just fix the symptom.
> 

Since we (at least my company) has already get benifits from Public Open
Source, we should try to provide the contribution back to Public Open
Source.

Providing contributions to Public Open Source is part of my duty (what
I should do).


> * You have made an (understandable) mistake with this particular
>   patch. It would have been nice if you had not made it, but I
>   can see that you are still learning about these things. There
>   is a fine line between what makes sense to be enabled as a
>   'compile test' and what should better be left disabled by
>   Kconfig.
> 

We have to meet three roles: 'user', 'provider' and 'tester' (which is
may mad user, and not quite familiar with the details).

For 'user', they really need 'COMPILE_TEST', so it should be added into
kernel wide. And 'user' often thinks the 'tester' is just a 'mad user'
for 'tester' offten does "mad things" which will be useless in real
world.

For 'provider', he/she often feels the 'tester' is not familiar the
details (in fact, they really not familiar), but he/she has to discuss
with 'tester' (especially 'user' does not care about it). He/She really
feels it is just boring and waste time.

Instead of discussing the details, 'tester' should only provide the
related proof and only can discus the related API, he/she wants the
'provider' to explain about the proof and make the API clearer to every
one (not only for 'expert').

Now, I think, I may just play a 'tester' role for 'asm-generic'.


> * When experienced developers tell you that you are mistaken, you
>   need to make an effort to understand what the mistake was so you
>   can learn from it and not make the same mistake again. If you
>   make the same mistakes again, maintainers will get annoyed and
>   ignore you (or worse), which is not a good situation to be
>   in when you want to get your patches merged.

'tester' wants the 'provider' to explain the proof:

  e.g. 'COMPILE_TEST' help contents whether really say: "can allow 'COMIPLE_TEST=y' in architectures which no related HW support"
  e.g. If compile fails because of no HW support with "COMPILE_TEST=y", can we still let it suspending ?
  e.g. Does it still count an issue, although in real world, it may not happen, at least now ?

'tester' also wants the 'provider' to explain 'asm-generic':

  Arnd said:
    "It's a set of examples for the architectures to look at and include if they want to"
  Steven saind:
    "The purpose of asm-generic is to add a standard infrastructure that some archs may be able to optimize."

  (In fact, they are not precisely the same).

  Did 'provider' have the related document for it (I guess so, could you provide the related location), thanks ?

  according to the definition of 'asm-generic' (either of them):
    the 'CONFIG_BUG' need really remove from 'asm-generic', for it is only related with some of architectures, not generic enough for all architectures
      (we can continue to discus it in the related thread).
    it belongs architectures wide, not kernel wide, is it better to move "./include/asm-generic" to "./arch/asm-default" or "./arch/asm-standard" ?

'tester' also wants to try something (but maybe incorrect).

  one sample for string, its value has 4 kinds: 'volatile string', 'const string', '""', 'NULL'.  ('""' is not equal to 'NULL').
  may we also have the 4 kinds: 'HAS_IOMAP', 'NOMMU', 'COMPILE_TEST', 'N/A' ('COMPILE_TEST' is not equal to 'N/A')?

  (this is maybe just boring or wast time, need not reply).


Thanks.
-- 
Chen Gang

Re: [uml-user] [PATCH] include/asm-generic/io.h: add dummy fuctions to support 'COMPILE_TEST' in 'asm-generic'.

[Arnd B. <ar...@ar...>]

On Friday 05 July 2013, Chen Gang F T wrote:
> Hello All:
> 
> It seems 'asm-generic' dislikes 'mad users' (e.g allmodconfig,
> randconfig, and me).
> 
> I guess the main reason is: 'asm-generic' thinks what mad users talk
> about is useless in real world, so it is just noisy.
> 
> I can understand, at least what I talk about is not for urgent things.
> (maybe 'asm-generic' also thinks it not important either, every members
> have their own opinions).
> 
> Next, I still use allmodconfig/randconfig for some architectures which I
> am interested in (and also for learning compilers), but I will skip all
> things which are related with 'asm-generic', since it dislikes me (a mad
> user).

As the asm-generic maintainer I think I have to clarify a few things:

* Build-time fixes for warnings and randconfig errors are good,
  and you have sent a number of good bug fixes all over the kernel,
  I definitely welcome getting more of those. In many cases the
  fix is trivial and obvious, in other cases you need to know
  much more of the background to understand what the underlying
  problem is and why you should not just fix the symptom.

* You have made an (understandable) mistake with this particular
  patch. It would have been nice if you had not made it, but I
  can see that you are still learning about these things. There
  is a fine line between what makes sense to be enabled as a
  'compile test' and what should better be left disabled by
  Kconfig.

* When experienced developers tell you that you are mistaken, you
  need to make an effort to understand what the mistake was so you
  can learn from it and not make the same mistake again. If you
  make the same mistakes again, maintainers will get annoyed and
  ignore you (or worse), which is not a good situation to be
  in when you want to get your patches merged.

	Arnd

Re: [uml-user] [PATCH] include/asm-generic/io.h: add dummy fuctions to support 'COMPILE_TEST' in 'asm-generic'.

[Chen G. F T <che...@gm...>]

Hello All:

It seems 'asm-generic' dislikes 'mad users' (e.g allmodconfig,
randconfig, and me).

I guess the main reason is: 'asm-generic' thinks what mad users talk
about is useless in real world, so it is just noisy.

I can understand, at least what I talk about is not for urgent things.
(maybe 'asm-generic' also thinks it not important either, every members
have their own opinions).

Next, I still use allmodconfig/randconfig for some architectures which I
am interested in (and also for learning compilers), but I will skip all
things which are related with 'asm-generic', since it dislikes me (a mad
user).

At last, I make an apologize to 'asm-generic' for my mad discussing.

Bye !!


On 07/05/2013 08:48 AM, Chen Gang F T wrote:
> On 07/05/2013 08:14 AM, Stephen Rothwell wrote:
>> On Fri, 05 Jul 2013 08:03:31 +0800 Chen Gang F T <che...@gm...> wrote:
>>>>
>>>> When a module select "COMPILE_TEST=y" (e.g with allmodconfig), it has
>>>> right to compile under the architecture which no related HW support.
>>>>
>>>> If it can not pass compiling, at least it is not the module's issue,
>>>> neither the architecture's issue.
>>>>
>>>> We have to look for who has duty on it. At least now, it seems only
>>>> 'asm-generic' can be qualified to play this unlucky role.
>> You keep saying this, but others have told you that this is not the
>> problem.
>>
> 
> In real world, it is not the problem.
> 
> But for 'mad users' (e.g. allmodconfig, randconfig, and me too), they
> have not provided enough reason for it (prove that is not a problem for
> 'mad users').
> 
> 
>>>> Could you provide your suggestions or completions for this issue ?
>> If something doesn't build for a particular config, then either it needs
>> to be fixed or excluded from building in that particular config.
> 
> I agree with you, if get rid of 'COMPILE_TEST'.
> 
> Thanks.
> 


-- 
Chen Gang

Re: [uml-user] [PATCH] include/asm-generic/io.h: add dummy fuctions to support 'COMPILE_TEST' in 'asm-generic'.

[Chen G. F T <che...@gm...>]

On 07/05/2013 08:12 AM, Greg KH wrote:
> I'm done with this thread, it's madness..

Yeah, especially discussing with 'mad users' (e.g. allmodconfig,
randconfig, and me too).  ;-)


Thanks.
-- 
Chen Gang

Re: [uml-user] [PATCH] include/asm-generic/io.h: add dummy fuctions to support 'COMPILE_TEST' in 'asm-generic'.

[Chen G. F T <che...@gm...>]

On 07/05/2013 08:14 AM, Stephen Rothwell wrote:
> On Fri, 05 Jul 2013 08:03:31 +0800 Chen Gang F T <che...@gm...> wrote:
>> >
>> > When a module select "COMPILE_TEST=y" (e.g with allmodconfig), it has
>> > right to compile under the architecture which no related HW support.
>> > 
>> > If it can not pass compiling, at least it is not the module's issue,
>> > neither the architecture's issue.
>> > 
>> > We have to look for who has duty on it. At least now, it seems only
>> > 'asm-generic' can be qualified to play this unlucky role.
> You keep saying this, but others have told you that this is not the
> problem.
> 

In real world, it is not the problem.

But for 'mad users' (e.g. allmodconfig, randconfig, and me too), they
have not provided enough reason for it (prove that is not a problem for
'mad users').


>> > Could you provide your suggestions or completions for this issue ?
> If something doesn't build for a particular config, then either it needs
> to be fixed or excluded from building in that particular config.

I agree with you, if get rid of 'COMPILE_TEST'.

Thanks.
-- 
Chen Gang

Re: [uml-user] [PATCH] include/asm-generic/io.h: add dummy fuctions to support 'COMPILE_TEST' in 'asm-generic'.

[Chen G. <gan...@as...>]

On 07/05/2013 08:12 AM, Greg KH wrote:
> On Fri, Jul 05, 2013 at 08:03:31AM +0800, Chen Gang F T wrote:
>> > On 07/04/2013 05:25 PM, Arnd Bergmann wrote:
>>> > > On Thursday 04 July 2013, Chen Gang wrote:
>>> > > 
>>>>> > >> > --------------------------patch begin----------------------------------
>>>>> > >> > 
>>>>> > >> > 'asm-generic' need provide necessary configuration checking, if can't
>>>>> > >> > pass checking, 'asm-generic' shouldn't implement it.
>>>>> > >> > 
>>>>> > >> > For 'COMPILE_TEST', according to its help contents, 'asm-generic' need
>>>>> > >> > let it pass configuration checking, and provide related dummy contents
>>>>> > >> > for it.
>>>>> > >> > 
>>>>> > >> > Part of 'COMPLE_TEST' help contents in "init/Kconfig":
>>>>> > >> > 
>>>>> > >> >   "...Despite they cannot be loaded there (or even when they load they cannot be used due to missing HW support)..."
>>>>> > >> > 
>>>>> > >> > One sample for using 'COMPILE_TEST':
>>>>> > >> > 
>>>>> > >> >   'PTP_1588_CLOCK_PCH' in drivers/ptp/Kconfig, which need depend on 'HAS_IOMEM'.
>>> > > Then please submit a patch that adds the 'depends on HAS_IOMEM' line there.
>>> > > That line was clearly left out by accident.
>>> > > 
>> > 
>> > Yes, I will send the related patch for it (I have sent one, but that
>> > seems incorrect, I will send patch v2 for that, after this patch
>> > finishes discussing).
>> > 
>> > But excluding 'PTP_1588_CLOCK_PCH' own issue, it is as a sample for our
>> > discussion (If "COMPILE_TEST=y", it should can be compiled under the
>> > archs which no 'HAS_IOMEM').
>> > 
>> > 
>>>>> > >> > Signed-off-by: Chen Gang <gan...@as...>
>>>>> > >> > ---
>>>>> > >> >  include/asm-generic/io.h |   22 ++++++++++++++++++----
>>>>> > >> >  1 files changed, 18 insertions(+), 4 deletions(-)
>>>>> > >> > 
>>>>> > >> > diff --git a/include/asm-generic/io.h b/include/asm-generic/io.h
>>>>> > >> > index d5afe96..301ce80 100644
>>>>> > >> > --- a/include/asm-generic/io.h
>>>>> > >> > +++ b/include/asm-generic/io.h
>>>>> > >> > @@ -303,13 +303,18 @@ static inline void *phys_to_virt(unsigned long address)
>>>>> > >> >  /*
>>>>> > >> >   * Change "struct page" to physical address.
>>>>> > >> >   *
>>>>> > >> > - * This implementation is for the no-MMU case only... if you have an MMU
>>>>> > >> > - * you'll need to provide your own definitions.
>>>>> > >> > + * This for the no-MMU, or no-IOMEM but still try to COMPILE_TEST cases.
>>>>> > >> > + * if you have an MMU and IOMEM, you'll need to provide your own definitions.
>>>>> > >> >   */
>>>>> > >> > -#ifndef CONFIG_MMU
>>>>> > >> > +#if !defined(CONFIG_MMU) || \
>>>>> > >> > +	(!defined(CONFIG_HAS_IOMEM) && defined(CONFIG_COMPILE_TEST))
>>>>> > >> >  static inline void __iomem *ioremap(phys_addr_t offset, unsigned long size)
>>>>> > >> >  {
>>>>> > >> > +#if !defined(CONFIG_MMU)
>>>>> > >> >  	return (void __iomem*) (unsigned long)offset;
>>>>> > >> > +#else
>>>>> > >> > +	return NULL;
>>>>> > >> > +#endif
>>>>> > >> >  }
>>>>> > >> >  
>>>>> > >> >  #define __ioremap(offset, size, flags)	ioremap(offset, size)
>>> > > This is wrong for multiple reasons, all of which have been discussed in
>>> > > this thread before.
>> > 
>> > Hmm..., COMPILE_TEST has integrated into 3.11 (at least can be found in
>> > next tree).
>> > 
>> > When a module select "COMPILE_TEST=y" (e.g with allmodconfig), it has
>> > right to compile under the architecture which no related HW support.
> That is not true at all, and is not what COMPILE_TEST means.
> 

Below is the 'COMPILE_TEST' help contents.

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.

Does a module have no right to choose "COMPILE_TEST=y" under the
architecture which no related HW support ?

Or I misunderstand the help contents ?

>> > If it can not pass compiling, at least it is not the module's issue,
>> > neither the architecture's issue.
> What?
> 

If it can not pass compiling because of HW not support when
"COMPILE_TEST=y", it is not the module's issue, neither the
architecture's issue.

>> > We have to look for who has duty on it. At least now, it seems only
>> > 'asm-generic' can be qualified to play this unlucky role.
> Huh?
> 
> Look, asm-generic is not what you think it is it seems, nor is
> COMPILE_TEST, which has caused this whole mess of a thread.  Please
> start over, learn what asm-generic is there for, and used for today.
> Same goes for COMPILE_TEST.
> 

At least, we can not suspend this issue. It is not suitable to fix
module by force (if multiple modules want "COMPILE_TEST=y", we need fix
multiple various times in various areas).


> I'm done with this thread, it's madness...

We are just discussing, every member has right to reply or not.

If no members reply, I will (of cause) not continue to send repeated
contents.

And excuse me, some contents are really repeated multiple times because
of some of members need it for discussion.


Thanks.
-- 
Chen Gang

Re: [uml-user] [PATCH] include/asm-generic/io.h: add dummy fuctions to support 'COMPILE_TEST' in 'asm-generic'.

[Stephen R. <sf...@ca...>]

Hi,

On Fri, 05 Jul 2013 08:03:31 +0800 Chen Gang F T <che...@gm...> wrote:
>
> When a module select "COMPILE_TEST=y" (e.g with allmodconfig), it has
> right to compile under the architecture which no related HW support.
> 
> If it can not pass compiling, at least it is not the module's issue,
> neither the architecture's issue.
> 
> We have to look for who has duty on it. At least now, it seems only
> 'asm-generic' can be qualified to play this unlucky role.

You keep saying this, but others have told you that this is not the
problem.

> Could you provide your suggestions or completions for this issue ?

If something doesn't build for a particular config, then either it needs
to be fixed or excluded from building in that particular config.

-- 
Cheers,
Stephen Rothwell                    sf...@ca...

Re: [uml-user] [PATCH] include/asm-generic/io.h: add dummy fuctions to support 'COMPILE_TEST' in 'asm-generic'.

[Greg KH <gr...@li...>]

On Fri, Jul 05, 2013 at 08:03:31AM +0800, Chen Gang F T wrote:
> On 07/04/2013 05:25 PM, Arnd Bergmann wrote:
> > On Thursday 04 July 2013, Chen Gang wrote:
> > 
> >> > --------------------------patch begin----------------------------------
> >> > 
> >> > 'asm-generic' need provide necessary configuration checking, if can't
> >> > pass checking, 'asm-generic' shouldn't implement it.
> >> > 
> >> > For 'COMPILE_TEST', according to its help contents, 'asm-generic' need
> >> > let it pass configuration checking, and provide related dummy contents
> >> > for it.
> >> > 
> >> > Part of 'COMPLE_TEST' help contents in "init/Kconfig":
> >> > 
> >> >   "...Despite they cannot be loaded there (or even when they load they cannot be used due to missing HW support)..."
> >> > 
> >> > One sample for using 'COMPILE_TEST':
> >> > 
> >> >   'PTP_1588_CLOCK_PCH' in drivers/ptp/Kconfig, which need depend on 'HAS_IOMEM'.
> > Then please submit a patch that adds the 'depends on HAS_IOMEM' line there.
> > That line was clearly left out by accident.
> > 
> 
> Yes, I will send the related patch for it (I have sent one, but that
> seems incorrect, I will send patch v2 for that, after this patch
> finishes discussing).
> 
> But excluding 'PTP_1588_CLOCK_PCH' own issue, it is as a sample for our
> discussion (If "COMPILE_TEST=y", it should can be compiled under the
> archs which no 'HAS_IOMEM').
> 
> 
> >> > Signed-off-by: Chen Gang <gan...@as...>
> >> > ---
> >> >  include/asm-generic/io.h |   22 ++++++++++++++++++----
> >> >  1 files changed, 18 insertions(+), 4 deletions(-)
> >> > 
> >> > diff --git a/include/asm-generic/io.h b/include/asm-generic/io.h
> >> > index d5afe96..301ce80 100644
> >> > --- a/include/asm-generic/io.h
> >> > +++ b/include/asm-generic/io.h
> >> > @@ -303,13 +303,18 @@ static inline void *phys_to_virt(unsigned long address)
> >> >  /*
> >> >   * Change "struct page" to physical address.
> >> >   *
> >> > - * This implementation is for the no-MMU case only... if you have an MMU
> >> > - * you'll need to provide your own definitions.
> >> > + * This for the no-MMU, or no-IOMEM but still try to COMPILE_TEST cases.
> >> > + * if you have an MMU and IOMEM, you'll need to provide your own definitions.
> >> >   */
> >> > -#ifndef CONFIG_MMU
> >> > +#if !defined(CONFIG_MMU) || \
> >> > +	(!defined(CONFIG_HAS_IOMEM) && defined(CONFIG_COMPILE_TEST))
> >> >  static inline void __iomem *ioremap(phys_addr_t offset, unsigned long size)
> >> >  {
> >> > +#if !defined(CONFIG_MMU)
> >> >  	return (void __iomem*) (unsigned long)offset;
> >> > +#else
> >> > +	return NULL;
> >> > +#endif
> >> >  }
> >> >  
> >> >  #define __ioremap(offset, size, flags)	ioremap(offset, size)
> > This is wrong for multiple reasons, all of which have been discussed in
> > this thread before.
> 
> Hmm..., COMPILE_TEST has integrated into 3.11 (at least can be found in
> next tree).
> 
> When a module select "COMPILE_TEST=y" (e.g with allmodconfig), it has
> right to compile under the architecture which no related HW support.

That is not true at all, and is not what COMPILE_TEST means.

> If it can not pass compiling, at least it is not the module's issue,
> neither the architecture's issue.

What?

> We have to look for who has duty on it. At least now, it seems only
> 'asm-generic' can be qualified to play this unlucky role.

Huh?

Look, asm-generic is not what you think it is it seems, nor is
COMPILE_TEST, which has caused this whole mess of a thread.  Please
start over, learn what asm-generic is there for, and used for today.
Same goes for COMPILE_TEST.

I'm done with this thread, it's madness...

greg k-h

Re: [uml-user] [PATCH] include/asm-generic/io.h: add dummy fuctions to support 'COMPILE_TEST' in 'asm-generic'.

[Chen G. <gan...@as...>]

On 07/04/2013 04:09 PM, Geert Uytterhoeven wrote:
> On Thu, Jul 4, 2013 at 8:12 AM, Greg KH <gr...@li...> wrote:
>> > On Thu, Jul 04, 2013 at 12:50:31PM +0800, Chen Gang wrote:
>>> >> On 07/04/2013 12:08 PM, Greg KH wrote:
>>>>>> >> >> > config COMPILE_TEST
>>>>>> >> >> >        bool "Compile also drivers which will not load"
>>>>>> >> >> >        default n
>>>> >> > This has _nothing_ to do with asm-generic, sorry.  Please don't confuse
>>>> >> > the issue.
>>> >>
>>> >> But when I choose allmodconfig, then "COMPILE_TEST=y". this may allow a
>>> >> module to compile under the architectures which no related HW support.
>>> >>
>>> >> When cause compiling issue (HW not support), it is not module's issue,
>>> >> we can not 'fix' module by force, and it is not architecture's issue,
>>> >> either.
>>> >>
>>> >> So we have to look for who has duty for this issue. At least now, it
>>> >> seems only 'asm-generic' can be qualified to play this unlucky role.
>> >
>> > You seem to not understand what asm-generic is, or does, or I still do
>> > not understand what you are proposing.
>> >
>> > Please send a patch showing what you are trying to do here, so that we
>> > can properly understand.
> The patch is in the first email of this thread:
> https://lkml.org/lkml/2013/7/1/641

Yeah, check history directly may be more precise.


Thanks.
-- 
Chen Gang

Re: [uml-user] [PATCH] include/asm-generic/io.h: add dummy fuctions to support 'COMPILE_TEST' in 'asm-generic'.

[Chen G. F T <che...@gm...>]

On 07/04/2013 05:25 PM, Arnd Bergmann wrote:
> On Thursday 04 July 2013, Chen Gang wrote:
> 
>> > --------------------------patch begin----------------------------------
>> > 
>> > 'asm-generic' need provide necessary configuration checking, if can't
>> > pass checking, 'asm-generic' shouldn't implement it.
>> > 
>> > For 'COMPILE_TEST', according to its help contents, 'asm-generic' need
>> > let it pass configuration checking, and provide related dummy contents
>> > for it.
>> > 
>> > Part of 'COMPLE_TEST' help contents in "init/Kconfig":
>> > 
>> >   "...Despite they cannot be loaded there (or even when they load they cannot be used due to missing HW support)..."
>> > 
>> > One sample for using 'COMPILE_TEST':
>> > 
>> >   'PTP_1588_CLOCK_PCH' in drivers/ptp/Kconfig, which need depend on 'HAS_IOMEM'.
> Then please submit a patch that adds the 'depends on HAS_IOMEM' line there.
> That line was clearly left out by accident.
> 

Yes, I will send the related patch for it (I have sent one, but that
seems incorrect, I will send patch v2 for that, after this patch
finishes discussing).

But excluding 'PTP_1588_CLOCK_PCH' own issue, it is as a sample for our
discussion (If "COMPILE_TEST=y", it should can be compiled under the
archs which no 'HAS_IOMEM').


>> > Signed-off-by: Chen Gang <gan...@as...>
>> > ---
>> >  include/asm-generic/io.h |   22 ++++++++++++++++++----
>> >  1 files changed, 18 insertions(+), 4 deletions(-)
>> > 
>> > diff --git a/include/asm-generic/io.h b/include/asm-generic/io.h
>> > index d5afe96..301ce80 100644
>> > --- a/include/asm-generic/io.h
>> > +++ b/include/asm-generic/io.h
>> > @@ -303,13 +303,18 @@ static inline void *phys_to_virt(unsigned long address)
>> >  /*
>> >   * Change "struct page" to physical address.
>> >   *
>> > - * This implementation is for the no-MMU case only... if you have an MMU
>> > - * you'll need to provide your own definitions.
>> > + * This for the no-MMU, or no-IOMEM but still try to COMPILE_TEST cases.
>> > + * if you have an MMU and IOMEM, you'll need to provide your own definitions.
>> >   */
>> > -#ifndef CONFIG_MMU
>> > +#if !defined(CONFIG_MMU) || \
>> > +	(!defined(CONFIG_HAS_IOMEM) && defined(CONFIG_COMPILE_TEST))
>> >  static inline void __iomem *ioremap(phys_addr_t offset, unsigned long size)
>> >  {
>> > +#if !defined(CONFIG_MMU)
>> >  	return (void __iomem*) (unsigned long)offset;
>> > +#else
>> > +	return NULL;
>> > +#endif
>> >  }
>> >  
>> >  #define __ioremap(offset, size, flags)	ioremap(offset, size)
> This is wrong for multiple reasons, all of which have been discussed in
> this thread before.

Hmm..., COMPILE_TEST has integrated into 3.11 (at least can be found in
next tree).

When a module select "COMPILE_TEST=y" (e.g with allmodconfig), it has
right to compile under the architecture which no related HW support.

If it can not pass compiling, at least it is not the module's issue,
neither the architecture's issue.

We have to look for who has duty on it. At least now, it seems only
'asm-generic' can be qualified to play this unlucky role.


Could you provide your suggestions or completions for this issue ?


Thanks.
-- 
Chen Gang

Re: [uml-user] [PATCH] include/asm-generic/io.h: add dummy fuctions to support 'COMPILE_TEST' in 'asm-generic'.

[Arnd B. <ar...@ar...>]

On Thursday 04 July 2013, Chen Gang wrote:

> --------------------------patch begin----------------------------------
> 
> 'asm-generic' need provide necessary configuration checking, if can't
> pass checking, 'asm-generic' shouldn't implement it.
> 
> For 'COMPILE_TEST', according to its help contents, 'asm-generic' need
> let it pass configuration checking, and provide related dummy contents
> for it.
> 
> Part of 'COMPLE_TEST' help contents in "init/Kconfig":
> 
>   "...Despite they cannot be loaded there (or even when they load they cannot be used due to missing HW support)..."
> 
> One sample for using 'COMPILE_TEST':
> 
>   'PTP_1588_CLOCK_PCH' in drivers/ptp/Kconfig, which need depend on 'HAS_IOMEM'.

Then please submit a patch that adds the 'depends on HAS_IOMEM' line there.
That line was clearly left out by accident.

> Signed-off-by: Chen Gang <gan...@as...>
> ---
>  include/asm-generic/io.h |   22 ++++++++++++++++++----
>  1 files changed, 18 insertions(+), 4 deletions(-)
> 
> diff --git a/include/asm-generic/io.h b/include/asm-generic/io.h
> index d5afe96..301ce80 100644
> --- a/include/asm-generic/io.h
> +++ b/include/asm-generic/io.h
> @@ -303,13 +303,18 @@ static inline void *phys_to_virt(unsigned long address)
>  /*
>   * Change "struct page" to physical address.
>   *
> - * This implementation is for the no-MMU case only... if you have an MMU
> - * you'll need to provide your own definitions.
> + * This for the no-MMU, or no-IOMEM but still try to COMPILE_TEST cases.
> + * if you have an MMU and IOMEM, you'll need to provide your own definitions.
>   */
> -#ifndef CONFIG_MMU
> +#if !defined(CONFIG_MMU) || \
> +	(!defined(CONFIG_HAS_IOMEM) && defined(CONFIG_COMPILE_TEST))
>  static inline void __iomem *ioremap(phys_addr_t offset, unsigned long size)
>  {
> +#if !defined(CONFIG_MMU)
>  	return (void __iomem*) (unsigned long)offset;
> +#else
> +	return NULL;
> +#endif
>  }
>  
>  #define __ioremap(offset, size, flags)	ioremap(offset, size)

This is wrong for multiple reasons, all of which have been discussed in
this thread before.

NAK

Re: [uml-user] [PATCH] include/asm-generic/io.h: add dummy fuctions to support 'COMPILE_TEST' in 'asm-generic'.

[Geert U. <ge...@li...>]

On Thu, Jul 4, 2013 at 8:12 AM, Greg KH <gr...@li...> wrote:
> On Thu, Jul 04, 2013 at 12:50:31PM +0800, Chen Gang wrote:
>> On 07/04/2013 12:08 PM, Greg KH wrote:
>> >> > config COMPILE_TEST
>> >> >        bool "Compile also drivers which will not load"
>> >> >        default n
>> > This has _nothing_ to do with asm-generic, sorry.  Please don't confuse
>> > the issue.
>>
>> But when I choose allmodconfig, then "COMPILE_TEST=y". this may allow a
>> module to compile under the architectures which no related HW support.
>>
>> When cause compiling issue (HW not support), it is not module's issue,
>> we can not 'fix' module by force, and it is not architecture's issue,
>> either.
>>
>> So we have to look for who has duty for this issue. At least now, it
>> seems only 'asm-generic' can be qualified to play this unlucky role.
>
> You seem to not understand what asm-generic is, or does, or I still do
> not understand what you are proposing.
>
> Please send a patch showing what you are trying to do here, so that we
> can properly understand.

The patch is in the first email of this thread:
https://lkml.org/lkml/2013/7/1/641

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [uml-user] [PATCH] include/asm-generic/io.h: add dummy fuctions to support 'COMPILE_TEST' in 'asm-generic'.

[Chen G. <gan...@as...>]

On 07/04/2013 02:12 PM, Greg KH wrote:
> On Thu, Jul 04, 2013 at 12:50:31PM +0800, Chen Gang wrote:
>> On 07/04/2013 12:08 PM, Greg KH wrote:
>>>>> config COMPILE_TEST
>>>>>        bool "Compile also drivers which will not load"
>>>>>        default n
>>> This has _nothing_ to do with asm-generic, sorry.  Please don't confuse
>>> the issue.
>>
>> But when I choose allmodconfig, then "COMPILE_TEST=y". this may allow a
>> module to compile under the architectures which no related HW support.
>>
>> When cause compiling issue (HW not support), it is not module's issue,
>> we can not 'fix' module by force, and it is not architecture's issue,
>> either.
>>
>> So we have to look for who has duty for this issue. At least now, it
>> seems only 'asm-generic' can be qualified to play this unlucky role.
> 
> You seem to not understand what asm-generic is, or does, or I still do
> not understand what you are proposing.
> 

Maybe both/neither of us.  :-)

> Please send a patch showing what you are trying to do here, so that we
> can properly understand.
> 

Please help to check the patch below, thanks.

--------------------------patch begin----------------------------------

'asm-generic' need provide necessary configuration checking, if can't
pass checking, 'asm-generic' shouldn't implement it.

For 'COMPILE_TEST', according to its help contents, 'asm-generic' need
let it pass configuration checking, and provide related dummy contents
for it.

Part of 'COMPLE_TEST' help contents in "init/Kconfig":

  "...Despite they cannot be loaded there (or even when they load they cannot be used due to missing HW support)..."

One sample for using 'COMPILE_TEST':

  'PTP_1588_CLOCK_PCH' in drivers/ptp/Kconfig, which need depend on 'HAS_IOMEM'.


Signed-off-by: Chen Gang <gan...@as...>
---
 include/asm-generic/io.h |   22 ++++++++++++++++++----
 1 files changed, 18 insertions(+), 4 deletions(-)

diff --git a/include/asm-generic/io.h b/include/asm-generic/io.h
index d5afe96..301ce80 100644
--- a/include/asm-generic/io.h
+++ b/include/asm-generic/io.h
@@ -303,13 +303,18 @@ static inline void *phys_to_virt(unsigned long address)
 /*
  * Change "struct page" to physical address.
  *
- * This implementation is for the no-MMU case only... if you have an MMU
- * you'll need to provide your own definitions.
+ * This for the no-MMU, or no-IOMEM but still try to COMPILE_TEST cases.
+ * if you have an MMU and IOMEM, you'll need to provide your own definitions.
  */
-#ifndef CONFIG_MMU
+#if !defined(CONFIG_MMU) || \
+	(!defined(CONFIG_HAS_IOMEM) && defined(CONFIG_COMPILE_TEST))
 static inline void __iomem *ioremap(phys_addr_t offset, unsigned long size)
 {
+#if !defined(CONFIG_MMU)
 	return (void __iomem*) (unsigned long)offset;
+#else
+	return NULL;
+#endif
 }
 
 #define __ioremap(offset, size, flags)	ioremap(offset, size)
@@ -325,7 +330,7 @@ static inline void __iomem *ioremap(phys_addr_t offset, unsigned long size)
 static inline void iounmap(void __iomem *addr)
 {
 }
-#endif /* CONFIG_MMU */
+#endif /* !CONFIG_MMU || (!CONFIG_HAS_IOMEM && CONFIG_COMPILE_TEST) */
 
 #ifdef CONFIG_HAS_IOPORT
 #ifndef CONFIG_GENERIC_IOMAP
@@ -341,6 +346,15 @@ static inline void ioport_unmap(void __iomem *p)
 extern void __iomem *ioport_map(unsigned long port, unsigned int nr);
 extern void ioport_unmap(void __iomem *p);
 #endif /* CONFIG_GENERIC_IOMAP */
+#elif defined(CONFIG_COMPILE_TEST) /* CONFIG_HAS_IOPORT */
+static inline void __iomem *ioport_map(unsigned long port, unsigned int nr)
+{
+	return NULL;
+}
+
+static inline void ioport_unmap(void __iomem *p)
+{
+}
 #endif /* CONFIG_HAS_IOPORT */
 
 #ifndef xlate_dev_kmem_ptr
-- 
1.7.7.6



--------------------------patch end------------------------------------


Thanks.
-- 
Chen Gang

-- 
Chen Gang

Re: [uml-user] [PATCH] include/asm-generic/io.h: add dummy fuctions to support 'COMPILE_TEST' in 'asm-generic'.

[Greg KH <gr...@li...>]

On Thu, Jul 04, 2013 at 12:50:31PM +0800, Chen Gang wrote:
> On 07/04/2013 12:08 PM, Greg KH wrote:
> >> > config COMPILE_TEST
> >> >        bool "Compile also drivers which will not load"
> >> >        default n
> > This has _nothing_ to do with asm-generic, sorry.  Please don't confuse
> > the issue.
> 
> But when I choose allmodconfig, then "COMPILE_TEST=y". this may allow a
> module to compile under the architectures which no related HW support.
> 
> When cause compiling issue (HW not support), it is not module's issue,
> we can not 'fix' module by force, and it is not architecture's issue,
> either.
> 
> So we have to look for who has duty for this issue. At least now, it
> seems only 'asm-generic' can be qualified to play this unlucky role.

You seem to not understand what asm-generic is, or does, or I still do
not understand what you are proposing.

Please send a patch showing what you are trying to do here, so that we
can properly understand.

greg k-h

Re: [uml-user] [PATCH] include/asm-generic/io.h: add dummy fuctions to support 'COMPILE_TEST' in 'asm-generic'.

[Chen G. <gan...@as...>]

On 07/04/2013 12:08 PM, Greg KH wrote:
> On Thu, Jul 04, 2013 at 11:26:53AM +0800, Chen Gang F T wrote:
>> > Please see the related comment in "init/Kconfig" of next-* tree.
> This is now in Linus's tree for 3.11.
> 

OK, thanks (at least for me, it is a good news).

>> > config COMPILE_TEST
>> >        bool "Compile also drivers which will not load"
>> >        default n
> This has _nothing_ to do with asm-generic, sorry.  Please don't confuse
> the issue.

But when I choose allmodconfig, then "COMPILE_TEST=y". this may allow a
module to compile under the architectures which no related HW support.

When cause compiling issue (HW not support), it is not module's issue,
we can not 'fix' module by force, and it is not architecture's issue,
either.

So we have to look for who has duty for this issue. At least now, it
seems only 'asm-generic' can be qualified to play this unlucky role.


Thanks.
-- 
Chen Gang

Re: [uml-user] [PATCH] include/asm-generic/io.h: add dummy fuctions to support 'COMPILE_TEST' in 'asm-generic'.

[Greg KH <gr...@li...>]

On Thu, Jul 04, 2013 at 11:26:53AM +0800, Chen Gang F T wrote:
> Please see the related comment in "init/Kconfig" of next-* tree.

This is now in Linus's tree for 3.11.

> config COMPILE_TEST
>        bool "Compile also drivers which will not load"
>        default n

This has _nothing_ to do with asm-generic, sorry.  Please don't confuse
the issue.

greg k-h

Re: [uml-user] [PATCH] include/asm-generic/io.h: add dummy fuctions to support 'COMPILE_TEST' in 'asm-generic'.

[Chen G. F T <che...@gm...>]

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

Re: [uml-user] [PATCH] include/asm-generic/io.h: add dummy fuctions to support 'COMPILE_TEST' in 'asm-generic'.

[Steven R. <ro...@go...>]

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.

> 
> 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?

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

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.

-- Steve