From: Arnd B. <ar...@ar...> - 2013-07-03 08:14:45
|
On Wednesday 03 July 2013, Chen Gang wrote: > On 07/02/2013 06:57 PM, Geert Uytterhoeven wrote: > > On Tue, Jul 2, 2013 at 10:00 AM, Chen Gang <gan...@as...> wrote: > >> > On 07/02/2013 03:19 PM, Geert Uytterhoeven wrote: > >>> >> On Tue, Jul 2, 2013 at 4:13 AM, Chen Gang <gan...@as...> wrote: > > I mean that COMPILE_TEST should exist in Kconfig files only. > > It's only meant to have more compile coverage, not to "fix" (through #ifdef) > > more code to make it compile. > > If so, can we allow the module to 'COMPILE_TEST' under one platform > which not support the related HW ? > > e.g. "...Despite they cannot be loaded there (or even when they load > they cannot be used due to missing HW support)...". There is a reason why ioremap and the associated functions make no sense on UML, and it remains important to not provide them here so we can find drivers that accidentally use them and are missing a dependency on HAS_IOMEM. > 'asm-generic' need provide generic layer to users (both architecture > guys and module guys). No. It's a set of examples for the architectures to look at and include if they want to. > So for 'default', it can depend on some conditions (e.g. HW support); > but for 'generic', it need try to be independent from any conditions. > > And it is also necessary for 'generic' to provide the configuration > checking features, but this checking must be no negative effect (or > consistent) with its 'generic' services. > > So it is necessary to check 'NOMMU', 'CONFIG_HAS_IOMEM' ..., but it > also necessary to consider about 'COMPILE_TEST' to be consistent with > its 'generic' services. The important distinction is between drivers we want to enable in COMPILE_TEST because they are written in a portable way but are just useless if you don't have the hardware, and other drivers that rely on an interface and that should not be built when that interface is not available. Arnd |
From: Chen G. <gan...@as...> - 2013-07-04 00:58:37
|
'asm-generic' neither belongs to architectures nor belongs to modules, it provides public services to both modules and architectures. 'COMPILE_TEST=y' will let 'asm-generic' provide self checking sevices to both modules and architectures (especially with allmodconfig and "EXTRA_CFLAGS=-W") For modules (especially which will run under the specific architecture soon), the developer can find more compiling issues before they really support it. For architectures, can let modules compile as much as possible (if "COMPILE_TEST=y"), it will give a better check for the architectures. At present, most of architectures (include various machine/cpu in an architecture) can not pass compiling with 'allmodconfig'. One of the main reasons is the HW of the specific architecture does not support. It is neither architectures issue nor modules issue, the root cause is: "now, 'asm-generic' doesn't provide the related necessary public services for it". Thanks. On 07/03/2013 04:43 PM, Chen Gang wrote: > On 07/03/2013 04:14 PM, Arnd Bergmann wrote: >> On Wednesday 03 July 2013, Chen Gang wrote: >>>> On 07/02/2013 06:57 PM, Geert Uytterhoeven wrote: >>>>>> On Tue, Jul 2, 2013 at 10:00 AM, Chen Gang <gan...@as...> wrote: >>>>>>>>>> On 07/02/2013 03:19 PM, Geert Uytterhoeven wrote: >>>>>>>>>>>>>> On Tue, Jul 2, 2013 at 4:13 AM, Chen Gang <gan...@as...> wrote: >>>>>> I mean that COMPILE_TEST should exist in Kconfig files only. >>>>>> It's only meant to have more compile coverage, not to "fix" (through #ifdef) >>>>>> more code to make it compile. >>>> >>>> If so, can we allow the module to 'COMPILE_TEST' under one platform >>>> which not support the related HW ? >>>> >>>> e.g. "...Despite they cannot be loaded there (or even when they load >>>> they cannot be used due to missing HW support)...". >> There is a reason why ioremap and the associated functions make no >> sense on UML, and it remains important to not provide them here >> so we can find drivers that accidentally use them and are missing >> a dependency on HAS_IOMEM. >> > > Yeah, it is necessary for "asm-generic" to provide the configuration > checking features (e.g. check HAS_IOMEM, HAS_IOMAP, ...). > > And it really make no sense on UML. > >>>> 'asm-generic' need provide generic layer to users (both architecture >>>> guys and module guys). >> No. It's a set of examples for the architectures to look at and >> include if they want to. >> > > If really just like what you said, I recommend to use "asm-default" > instead of "asm-generic". > > And for module guys, they have to use another 'generic' files instead > of current 'asm-generic', they really need some 'generic' things to > prevent the various definitions/implementations spread into anywhere. > >>>> So for 'default', it can depend on some conditions (e.g. HW support); >>>> but for 'generic', it need try to be independent from any conditions. >>>> >>>> And it is also necessary for 'generic' to provide the configuration >>>> checking features, but this checking must be no negative effect (or >>>> consistent) with its 'generic' services. >>>> >>>> So it is necessary to check 'NOMMU', 'CONFIG_HAS_IOMEM' ..., but it >>>> also necessary to consider about 'COMPILE_TEST' to be consistent with >>>> its 'generic' services. >> The important distinction is between drivers we want to enable in >> COMPILE_TEST because they are written in a portable way but are just >> useless if you don't have the hardware, and other drivers that rely >> on an interface and that should not be built when that interface >> is not available. > > For user/distributor, they are just like what you said above, but for > some of developers ... > > The comments of 'COMPILE_TEST' in init/Kconfig: > > 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. > > > Thanks. > -- Chen Gang |
From: Chen G. F T <che...@gm...> - 2013-07-04 03:28:27
|
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 |
From: Greg KH <gr...@li...> - 2013-07-04 04:08:18
|
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 |
From: Greg KH <gr...@li...> - 2013-07-04 01:11:39
|
On Thu, Jul 04, 2013 at 08:57:34AM +0800, Chen Gang wrote: > 'asm-generic' neither belongs to architectures nor belongs to modules, > it provides public services to both modules and architectures. That sentence does not make any sense to me. > 'COMPILE_TEST=y' will let 'asm-generic' provide self checking sevices to > both modules and architectures (especially with allmodconfig and > "EXTRA_CFLAGS=-W") No it doesn't. > For modules (especially which will run under the specific architecture > soon), the developer can find more compiling issues before they really > support it. Huh? > For architectures, can let modules compile as much as possible (if > "COMPILE_TEST=y"), it will give a better check for the architectures. > > At present, most of architectures (include various machine/cpu in an > architecture) can not pass compiling with 'allmodconfig'. One of the > main reasons is the HW of the specific architecture does not support. > > It is neither architectures issue nor modules issue, the root cause is: > "now, 'asm-generic' doesn't provide the related necessary public > services for it". That's not what asm-generic is for at all. confused, greg k-h |
From: Chen G. <gan...@as...> - 2013-07-04 01:51:44
|
On 07/04/2013 09:12 AM, Greg KH wrote: > On Thu, Jul 04, 2013 at 08:57:34AM +0800, Chen Gang wrote: >> > 'COMPILE_TEST=y' will let 'asm-generic' provide self checking sevices to >> > both modules and architectures (especially with allmodconfig and >> > "EXTRA_CFLAGS=-W") > No it doesn't. > "If add 'COMPILE_TEST=y' to 'asm-generic', it will provide self checking services to both modules and architectures" Is it correct ? >> > For modules (especially which will run under the specific architecture >> > soon), the developer can find more compiling issues before they really >> > support it. > Huh? > For developers, they may has hobby to let their code pass compiling as much as possible in the integrating environments, although the modules may not really load/run. >> > For architectures, can let modules compile as much as possible (if >> > "COMPILE_TEST=y"), it will give a better check for the architectures. >> > >> > At present, most of architectures (include various machine/cpu in an >> > architecture) can not pass compiling with 'allmodconfig'. One of the >> > main reasons is the HW of the specific architecture does not support. >> > >> > It is neither architectures issue nor modules issue, the root cause is: >> > "now, 'asm-generic' doesn't provide the related necessary public >> > services for it". > That's not what asm-generic is for at all. Hmm... at least, it is neither architectures issue nor modules issue. So we have to look for who have duty for it, since it is a 'generic' issue for many architectures and modules, we have to find it in 'generic' area (e.g. "./include/*"). At least now, it seems only "asm-generic/*" can play the unlucky role !! Or, do you think it is still the modules issue themselves ? Thanks. -- Chen Gang |
From: Chen G. <gan...@as...> - 2013-07-04 04:51:34
|
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 |
From: Greg KH <gr...@li...> - 2013-07-04 06:11:20
|
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 |
From: Geert U. <ge...@li...> - 2013-07-04 08:09:22
|
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 |
From: Chen G. <gan...@as...> - 2013-07-05 00:11:37
|
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 |
From: Chen G. <gan...@as...> - 2013-07-04 06:36:22
|
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 |
From: Arnd B. <ar...@ar...> - 2013-07-04 09:25:48
|
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 |
From: Chen G. F T <che...@gm...> - 2013-07-05 00:04:47
|
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 |
From: Greg KH <gr...@li...> - 2013-07-05 00:11:54
|
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 |
From: Chen G. <gan...@as...> - 2013-07-05 00:36:22
|
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 |
From: Chen G. F T <che...@gm...> - 2013-07-05 00:53:39
|
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 |
From: Stephen R. <sf...@ca...> - 2013-07-05 00:33:01
|
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... |
From: Chen G. F T <che...@gm...> - 2013-07-05 00:50:06
|
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 |
From: Arnd B. <ar...@ar...> - 2013-07-05 11:14:34
|
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 |
From: Chen G. F T <che...@gm...> - 2013-07-08 02:12:22
|
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 |
From: Steven R. <ro...@go...> - 2013-07-04 01:23:35
|
On Wed, 2013-07-03 at 18:12 -0700, Greg KH wrote: > confused, Good. I thought I was the only one. Confusion loves company, that way we can follow each other around in endless circles. -- Steve |
From: Chen G. F T <che...@gm...> - 2013-07-04 02:21:08
|
On 07/04/2013 09:23 AM, Steven Rostedt wrote: > On Wed, 2013-07-03 at 18:12 -0700, Greg KH wrote: > >> > confused, > Good. I thought I was the only one. Confusion loves company, that way we > can follow each other around in endless circles. If you think, this mail has already make noises to many other members, please reply mail next, which only contents the related members. And I will follow with the address which you provide. Thanks. -- Chen Gang |
From: Steven R. <ro...@go...> - 2013-07-04 02:03:22
|
On Thu, 2013-07-04 at 09:49 +0800, Chen Gang wrote: > Hmm... at least, it is neither architectures issue nor modules issue. > > So we have to look for who have duty for it, since it is a 'generic' > issue for many architectures and modules, we have to find it in > 'generic' area (e.g. "./include/*"). > > At least now, it seems only "asm-generic/*" can play the unlucky role !! > > Or, do you think it is still the modules issue themselves ? What problem are you trying to solve? asm-generic has been around for a long time, and so has allmodconfig. I'm unaware of any issues with either of them. But as my last email got blocked because your ISP thinks my ISP is a spambot (it's road runner, which I'm sure there are spammers), you wont get this anyway. -- Steve |
From: Chen G. F T <che...@gm...> - 2013-07-04 02:12:09
|
On 07/04/2013 10:03 AM, Steven Rostedt wrote: > On Thu, 2013-07-04 at 09:49 +0800, Chen Gang wrote: > >> > Hmm... at least, it is neither architectures issue nor modules issue. >> > >> > So we have to look for who have duty for it, since it is a 'generic' >> > issue for many architectures and modules, we have to find it in >> > 'generic' area (e.g. "./include/*"). >> > >> > At least now, it seems only "asm-generic/*" can play the unlucky role !! >> > >> > Or, do you think it is still the modules issue themselves ? > What problem are you trying to solve? asm-generic has been around for a > long time, and so has allmodconfig. I'm unaware of any issues with > either of them. > Select "COMPILE_TEST=y" with allmodconfig, but can not pass compiling in many architectures, one of the most reasons is "HW does not support". 'asm-generic' is really existent for a long time, and make an important role for both architectures and modules. > But as my last email got blocked because your ISP thinks my ISP is a > spambot (it's road runner, which I'm sure there are spammers), you wont > get this anyway. Oh, sorry for not reply the original mail, and did not see in my backup mail, now, I can use my backup mail to continue. Thanks. -- Chen Gang |
From: Steven R. <ro...@go...> - 2013-07-04 02:29:46
|
On Thu, 2013-07-04 at 10:10 +0800, Chen Gang F T wrote: > Select "COMPILE_TEST=y" with allmodconfig, but can not pass compiling in > many architectures, one of the most reasons is "HW does not support". > > 'asm-generic' is really existent for a long time, and make an important > role for both architectures and modules. > The purpose of asm-generic is to add a standard infrastructure that some archs may be able to optimize. It's not so that all archs can compile all modules. I'm still confused by what you are trying to accomplish. -- Steve |