[PATCH for 2.6.28 stable] m68knommu: fix m68knommu defconfig can't build

All of lore.kernel.org
 help / color / mirror / Atom feed

* [PATCH for 2.6.28 stable] m68knommu: fix m68knommu defconfig can't build
@ 2008-12-30 10:44 ` KOSAKI Motohiro
  0 siblings, 0 replies; 16+ messages in thread
From: KOSAKI Motohiro @ 2008-12-30 10:44 UTC (permalink / raw)
  To: David S. Miller, Geert Uytterhoeven, Roman Zippel, Greg Ungerer,
	linux-m68k
  Cc: kosaki.motohiro


I guess nobody don't test m68knommu at all last three month.
Do we still need to maintain this architecture?


==
Currently, m68knommu defconfig can't build. it cause following error.

net/built-in.o: In function `skb_dma_map':
: undefined reference to `dma_mapping_error'
net/built-in.o: In function `skb_dma_unmap':
: undefined reference to `dma_unmap_single'
net/built-in.o: In function `skb_dma_unmap':
: undefined reference to `dma_unmap_page'
net/built-in.o: In function `skb_dma_map':
: undefined reference to `dma_map_single'
net/built-in.o: In function `skb_dma_map':
: undefined reference to `dma_map_page'
net/built-in.o: In function `skb_dma_map':
: undefined reference to `dma_unmap_page'
net/built-in.o: In function `skb_dma_map':
: undefined reference to `dma_unmap_single'

because
 - CONFIG_DMA depend on !NO_DMA
 - m68knommu always doesn't turn on NO_DMA
 - if CONFIG_PCI=n, m68knommu/include/asm/dma-magging.h include
    asm-generic/dma-mapping-broken.h
 - dma-mapping-broken.h generate link time error.
 - m68knommu defconfig doesn't have CONFIG_PCI
 - On the other hand, net/core/skb_dma_map.c assume CONFIG_DMA=y mean
   dma related function is callable

So, we want to turn on CONFIG_DMA if CONFIG_PCI=y only.


CC: David S. Miller <davem@davemloft.net>
CC: Geert Uytterhoeven <geert@linux-m68k.org>
CC: Roman Zippel <zippel@linux-m68k.org>
CC: Greg Ungerer <gerg@uclinux.org>
CC: linux-m68k@lists.linux-m68k.org
---
 arch/m68knommu/Kconfig |    3 +++
 1 file changed, 3 insertions(+)

Index: b/arch/m68knommu/Kconfig
===================================================================
--- a/arch/m68knommu/Kconfig	2008-12-25 08:26:37.000000000 +0900
+++ b/arch/m68knommu/Kconfig	2008-12-28 21:09:58.000000000 +0900
@@ -73,6 +73,9 @@ config GENERIC_CLOCKEVENTS
 config NO_IOPORT
 	def_bool y
 
+config NO_DMA
+	def_bool !PCI
+
 source "init/Kconfig"
 
 source "kernel/Kconfig.freezer"



^ permalink raw reply	[flat|nested] 16+ messages in thread

* [PATCH for 2.6.28 stable] m68knommu: fix m68knommu defconfig can't build
@ 2008-12-30 10:44 ` KOSAKI Motohiro
  0 siblings, 0 replies; 16+ messages in thread
From: KOSAKI Motohiro @ 2008-12-30 10:44 UTC (permalink / raw)
  To: David S. Miller, Geert Uytterhoeven, Roman Zippel, Greg Ungerer,
	linux-m68k, stable, LKML
  Cc: kosaki.motohiro


I guess nobody don't test m68knommu at all last three month.
Do we still need to maintain this architecture?


==
Currently, m68knommu defconfig can't build. it cause following error.

net/built-in.o: In function `skb_dma_map':
: undefined reference to `dma_mapping_error'
net/built-in.o: In function `skb_dma_unmap':
: undefined reference to `dma_unmap_single'
net/built-in.o: In function `skb_dma_unmap':
: undefined reference to `dma_unmap_page'
net/built-in.o: In function `skb_dma_map':
: undefined reference to `dma_map_single'
net/built-in.o: In function `skb_dma_map':
: undefined reference to `dma_map_page'
net/built-in.o: In function `skb_dma_map':
: undefined reference to `dma_unmap_page'
net/built-in.o: In function `skb_dma_map':
: undefined reference to `dma_unmap_single'

because
 - CONFIG_DMA depend on !NO_DMA
 - m68knommu always doesn't turn on NO_DMA
 - if CONFIG_PCI=n, m68knommu/include/asm/dma-magging.h include
    asm-generic/dma-mapping-broken.h
 - dma-mapping-broken.h generate link time error.
 - m68knommu defconfig doesn't have CONFIG_PCI
 - On the other hand, net/core/skb_dma_map.c assume CONFIG_DMA=y mean
   dma related function is callable

So, we want to turn on CONFIG_DMA if CONFIG_PCI=y only.


CC: David S. Miller <davem@davemloft.net>
CC: Geert Uytterhoeven <geert@linux-m68k.org>
CC: Roman Zippel <zippel@linux-m68k.org>
CC: Greg Ungerer <gerg@uclinux.org>
CC: linux-m68k@lists.linux-m68k.org
---
 arch/m68knommu/Kconfig |    3 +++
 1 file changed, 3 insertions(+)

Index: b/arch/m68knommu/Kconfig
===================================================================
--- a/arch/m68knommu/Kconfig	2008-12-25 08:26:37.000000000 +0900
+++ b/arch/m68knommu/Kconfig	2008-12-28 21:09:58.000000000 +0900
@@ -73,6 +73,9 @@ config GENERIC_CLOCKEVENTS
 config NO_IOPORT
 	def_bool y
 
+config NO_DMA
+	def_bool !PCI
+
 source "init/Kconfig"
 
 source "kernel/Kconfig.freezer"



^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [PATCH for 2.6.28 stable] m68knommu: fix m68knommu defconfig can't build
  2008-12-30 10:44 ` KOSAKI Motohiro
@ 2008-10-06  6:20   ` Greg Ungerer
  -1 siblings, 0 replies; 16+ messages in thread
From: Greg Ungerer @ 2008-10-06  6:20 UTC (permalink / raw)
  To: KOSAKI Motohiro
  Cc: David S. Miller, Geert Uytterhoeven, Roman Zippel, Greg Ungerer,
	linux-m68k, stable, LKML

Hi Kosako,

KOSAKI Motohiro wrote:
> I guess nobody don't test m68knommu at all last three month.
> Do we still need to maintain this architecture?

Yes, we do.

Regards
Greg



> ==
> Currently, m68knommu defconfig can't build. it cause following error.
> 
> net/built-in.o: In function `skb_dma_map':
> : undefined reference to `dma_mapping_error'
> net/built-in.o: In function `skb_dma_unmap':
> : undefined reference to `dma_unmap_single'
> net/built-in.o: In function `skb_dma_unmap':
> : undefined reference to `dma_unmap_page'
> net/built-in.o: In function `skb_dma_map':
> : undefined reference to `dma_map_single'
> net/built-in.o: In function `skb_dma_map':
> : undefined reference to `dma_map_page'
> net/built-in.o: In function `skb_dma_map':
> : undefined reference to `dma_unmap_page'
> net/built-in.o: In function `skb_dma_map':
> : undefined reference to `dma_unmap_single'
> 
> because
>  - CONFIG_DMA depend on !NO_DMA
>  - m68knommu always doesn't turn on NO_DMA
>  - if CONFIG_PCI=n, m68knommu/include/asm/dma-magging.h include
>     asm-generic/dma-mapping-broken.h
>  - dma-mapping-broken.h generate link time error.
>  - m68knommu defconfig doesn't have CONFIG_PCI
>  - On the other hand, net/core/skb_dma_map.c assume CONFIG_DMA=y mean
>    dma related function is callable
> 
> So, we want to turn on CONFIG_DMA if CONFIG_PCI=y only.
> 
> 
> CC: David S. Miller <davem@davemloft.net>
> CC: Geert Uytterhoeven <geert@linux-m68k.org>
> CC: Roman Zippel <zippel@linux-m68k.org>
> CC: Greg Ungerer <gerg@uclinux.org>
> CC: linux-m68k@lists.linux-m68k.org
> ---
>  arch/m68knommu/Kconfig |    3 +++
>  1 file changed, 3 insertions(+)
> 
> Index: b/arch/m68knommu/Kconfig
> ===================================================================
> --- a/arch/m68knommu/Kconfig	2008-12-25 08:26:37.000000000 +0900
> +++ b/arch/m68knommu/Kconfig	2008-12-28 21:09:58.000000000 +0900
> @@ -73,6 +73,9 @@ config GENERIC_CLOCKEVENTS
>  config NO_IOPORT
>  	def_bool y
>  
> +config NO_DMA
> +	def_bool !PCI
> +
>  source "init/Kconfig"
>  
>  source "kernel/Kconfig.freezer"
> 
> 
> 

-- 
------------------------------------------------------------------------
Greg Ungerer  --  Principal Engineer        EMAIL:     gerg@snapgear.com
SnapGear, a McAfee Company                  PHONE:       +61 7 3435 2888
825 Stanley St,                             FAX:         +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia         WEB: http://www.SnapGear.com

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [PATCH for 2.6.28 stable] m68knommu: fix m68knommu defconfig can't build
@ 2008-10-06  6:20   ` Greg Ungerer
  0 siblings, 0 replies; 16+ messages in thread
From: Greg Ungerer @ 2008-10-06  6:20 UTC (permalink / raw)
  To: KOSAKI Motohiro
  Cc: David S. Miller, Geert Uytterhoeven, Roman Zippel, Greg Ungerer,
	linux-m68k, stable, LKML

Hi Kosako,

KOSAKI Motohiro wrote:
> I guess nobody don't test m68knommu at all last three month.
> Do we still need to maintain this architecture?

Yes, we do.

Regards
Greg



> ==
> Currently, m68knommu defconfig can't build. it cause following error.
> 
> net/built-in.o: In function `skb_dma_map':
> : undefined reference to `dma_mapping_error'
> net/built-in.o: In function `skb_dma_unmap':
> : undefined reference to `dma_unmap_single'
> net/built-in.o: In function `skb_dma_unmap':
> : undefined reference to `dma_unmap_page'
> net/built-in.o: In function `skb_dma_map':
> : undefined reference to `dma_map_single'
> net/built-in.o: In function `skb_dma_map':
> : undefined reference to `dma_map_page'
> net/built-in.o: In function `skb_dma_map':
> : undefined reference to `dma_unmap_page'
> net/built-in.o: In function `skb_dma_map':
> : undefined reference to `dma_unmap_single'
> 
> because
>  - CONFIG_DMA depend on !NO_DMA
>  - m68knommu always doesn't turn on NO_DMA
>  - if CONFIG_PCI=n, m68knommu/include/asm/dma-magging.h include
>     asm-generic/dma-mapping-broken.h
>  - dma-mapping-broken.h generate link time error.
>  - m68knommu defconfig doesn't have CONFIG_PCI
>  - On the other hand, net/core/skb_dma_map.c assume CONFIG_DMA=y mean
>    dma related function is callable
> 
> So, we want to turn on CONFIG_DMA if CONFIG_PCI=y only.
> 
> 
> CC: David S. Miller <davem@davemloft.net>
> CC: Geert Uytterhoeven <geert@linux-m68k.org>
> CC: Roman Zippel <zippel@linux-m68k.org>
> CC: Greg Ungerer <gerg@uclinux.org>
> CC: linux-m68k@lists.linux-m68k.org
> ---
>  arch/m68knommu/Kconfig |    3 +++
>  1 file changed, 3 insertions(+)
> 
> Index: b/arch/m68knommu/Kconfig
> ===================================================================
> --- a/arch/m68knommu/Kconfig	2008-12-25 08:26:37.000000000 +0900
> +++ b/arch/m68knommu/Kconfig	2008-12-28 21:09:58.000000000 +0900
> @@ -73,6 +73,9 @@ config GENERIC_CLOCKEVENTS
>  config NO_IOPORT
>  	def_bool y
>  
> +config NO_DMA
> +	def_bool !PCI
> +
>  source "init/Kconfig"
>  
>  source "kernel/Kconfig.freezer"
> 
> 
> 

-- 
------------------------------------------------------------------------
Greg Ungerer  --  Principal Engineer        EMAIL:     gerg@snapgear.com
SnapGear, a McAfee Company                  PHONE:       +61 7 3435 2888
825 Stanley St,                             FAX:         +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia         WEB: http://www.SnapGear.com

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [PATCH for 2.6.28 stable] m68knommu: fix m68knommu defconfig can't build
  2008-10-06  6:20   ` Greg Ungerer
@ 2009-01-12 10:35     ` KOSAKI Motohiro
  -1 siblings, 0 replies; 16+ messages in thread
From: KOSAKI Motohiro @ 2009-01-12 10:35 UTC (permalink / raw)
  To: Greg Ungerer
  Cc: David S. Miller, Geert Uytterhoeven, Roman Zippel, Greg Ungerer,
	linux-m68k, stable, LKML

> Hi Kosako,
>
> KOSAKI Motohiro wrote:
>>
>> I guess nobody don't test m68knommu at all last three month.
>> Do we still need to maintain this architecture?
>
> Yes, we do.

ok. I don't have objection.
thank you.

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [PATCH for 2.6.28 stable] m68knommu: fix m68knommu defconfig can't build
@ 2009-01-12 10:35     ` KOSAKI Motohiro
  0 siblings, 0 replies; 16+ messages in thread
From: KOSAKI Motohiro @ 2009-01-12 10:35 UTC (permalink / raw)
  To: Greg Ungerer
  Cc: David S. Miller, Geert Uytterhoeven, Roman Zippel, Greg Ungerer,
	linux-m68k, stable, LKML

> Hi Kosako,
>
> KOSAKI Motohiro wrote:
>>
>> I guess nobody don't test m68knommu at all last three month.
>> Do we still need to maintain this architecture?
>
> Yes, we do.

ok. I don't have objection.
thank you.

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [PATCH for 2.6.28 stable] m68knommu: fix m68knommu defconfig can't build
  2008-10-06  6:20   ` Greg Ungerer
@ 2009-01-12 10:44     ` Paul Mundt
  -1 siblings, 0 replies; 16+ messages in thread
From: Paul Mundt @ 2009-01-12 10:44 UTC (permalink / raw)
  To: Greg Ungerer
  Cc: KOSAKI Motohiro, David S. Miller, Geert Uytterhoeven,
	Roman Zippel, Greg Ungerer, linux-m68k, stable, LKML

On Mon, Oct 06, 2008 at 04:20:06PM +1000, Greg Ungerer wrote:
> Hi Kosako,
> 
> KOSAKI Motohiro wrote:
> >I guess nobody don't test m68knommu at all last three month.
> >Do we still need to maintain this architecture?
> 
> Yes, we do.
> 
Any effort to get m68knommu folded in to m68k proper? This might help
with some of your bitrot issues.. And likely less work to do in
supporting those m68knommu parts that ship with MMUs ;-)

m68knommu is the only one of the mmu/nommu variants left that ships in
its own architecture directory rather than being folded in to its parent.
It would be good to get rid of it one of these days.

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [PATCH for 2.6.28 stable] m68knommu: fix m68knommu defconfig can't build
@ 2009-01-12 10:44     ` Paul Mundt
  0 siblings, 0 replies; 16+ messages in thread
From: Paul Mundt @ 2009-01-12 10:44 UTC (permalink / raw)
  To: Greg Ungerer
  Cc: KOSAKI Motohiro, David S. Miller, Geert Uytterhoeven,
	Roman Zippel, Greg Ungerer, linux-m68k, stable, LKML

On Mon, Oct 06, 2008 at 04:20:06PM +1000, Greg Ungerer wrote:
> Hi Kosako,
> 
> KOSAKI Motohiro wrote:
> >I guess nobody don't test m68knommu at all last three month.
> >Do we still need to maintain this architecture?
> 
> Yes, we do.
> 
Any effort to get m68knommu folded in to m68k proper? This might help
with some of your bitrot issues.. And likely less work to do in
supporting those m68knommu parts that ship with MMUs ;-)

m68knommu is the only one of the mmu/nommu variants left that ships in
its own architecture directory rather than being folded in to its parent.
It would be good to get rid of it one of these days.

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [PATCH for 2.6.28 stable] m68knommu: fix m68knommu defconfig can't build
  2009-01-12 10:44     ` Paul Mundt
  (?)
@ 2009-01-12 10:59     ` Sam Ravnborg
  -1 siblings, 0 replies; 16+ messages in thread
From: Sam Ravnborg @ 2009-01-12 10:59 UTC (permalink / raw)
  To: Paul Mundt, Greg Ungerer, KOSAKI Motohiro, David S. Miller,
	Geert Uytterhoeven <geer>

On Mon, Jan 12, 2009 at 07:44:47PM +0900, Paul Mundt wrote:
> On Mon, Oct 06, 2008 at 04:20:06PM +1000, Greg Ungerer wrote:
> > Hi Kosako,
> > 
> > KOSAKI Motohiro wrote:
> > >I guess nobody don't test m68knommu at all last three month.
> > >Do we still need to maintain this architecture?
> > 
> > Yes, we do.
> > 
> Any effort to get m68knommu folded in to m68k proper? This might help
> with some of your bitrot issues.. And likely less work to do in
> supporting those m68knommu parts that ship with MMUs ;-)
> 
> m68knommu is the only one of the mmu/nommu variants left that ships in
> its own architecture directory rather than being folded in to its parent.
> It would be good to get rid of it one of these days.

>From the outside it looks like there are indeed a whish to do so
but both m68k and m68knommu maintainers seems to be busy with other stuff.

Not that I can think of what is more important than to merge the two
architectures ;-)

If I get some spare time one day I have actually planned to try to
help a little - but that would require an active maintainer..

We just did the exercise with sparc/sparc64 unification and
if you forget the few times I broke sparc32 then it went well
with only limited problems.

One key factor why it went well was that patches were reviewed
and applied within a few days whch is why I stresses that the
maintainer needs spare time to support the effort.

	Sam

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [PATCH for 2.6.28 stable] m68knommu: fix m68knommu defconfig can't build
  2009-01-12 10:44     ` Paul Mundt
  (?)
  (?)
@ 2009-01-12 10:59     ` Sam Ravnborg
  2009-01-12 11:07         ` Ingo Molnar
  2009-01-12 11:12         ` Paul Mundt
  -1 siblings, 2 replies; 16+ messages in thread
From: Sam Ravnborg @ 2009-01-12 10:59 UTC (permalink / raw)
  To: Paul Mundt, Greg Ungerer, KOSAKI Motohiro, David S. Miller,
	Geert Uytterhoeven, Roman Zippel, Greg Ungerer, linux-m68k,
	stable, LKML

On Mon, Jan 12, 2009 at 07:44:47PM +0900, Paul Mundt wrote:
> On Mon, Oct 06, 2008 at 04:20:06PM +1000, Greg Ungerer wrote:
> > Hi Kosako,
> > 
> > KOSAKI Motohiro wrote:
> > >I guess nobody don't test m68knommu at all last three month.
> > >Do we still need to maintain this architecture?
> > 
> > Yes, we do.
> > 
> Any effort to get m68knommu folded in to m68k proper? This might help
> with some of your bitrot issues.. And likely less work to do in
> supporting those m68knommu parts that ship with MMUs ;-)
> 
> m68knommu is the only one of the mmu/nommu variants left that ships in
> its own architecture directory rather than being folded in to its parent.
> It would be good to get rid of it one of these days.

>From the outside it looks like there are indeed a whish to do so
but both m68k and m68knommu maintainers seems to be busy with other stuff.

Not that I can think of what is more important than to merge the two
architectures ;-)

If I get some spare time one day I have actually planned to try to
help a little - but that would require an active maintainer..

We just did the exercise with sparc/sparc64 unification and
if you forget the few times I broke sparc32 then it went well
with only limited problems.

One key factor why it went well was that patches were reviewed
and applied within a few days whch is why I stresses that the
maintainer needs spare time to support the effort.

	Sam

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [PATCH for 2.6.28 stable] m68knommu: fix m68knommu defconfig can't build
  2009-01-12 10:59     ` Sam Ravnborg
@ 2009-01-12 11:07         ` Ingo Molnar
  2009-01-12 11:12         ` Paul Mundt
  1 sibling, 0 replies; 16+ messages in thread
From: Ingo Molnar @ 2009-01-12 11:07 UTC (permalink / raw)
  To: Sam Ravnborg
  Cc: Paul Mundt, Greg Ungerer, KOSAKI Motohiro, David S. Miller,
	Geert Uytterhoeven, Roman Zippel, Greg Ungerer, linux-m68k,
	stable, LKML


* Sam Ravnborg <sam@ravnborg.org> wrote:

> We just did the exercise with sparc/sparc64 unification and if you 
> forget the few times I broke sparc32 then it went well with only limited 
> problems.

We also had the x86 unification finished in the past year which went very 
well too, so i can only encourage similar efforts.

> One key factor why it went well was that patches were reviewed and 
> applied within a few days whch is why I stresses that the maintainer 
> needs spare time to support the effort.

Yes.

Unification is the Linux meme of the century i guess ;-)

There's two main unification themes:

 - per arch unification (x86, powerpc, sparc

 - cross-arch unification: the moving of useful stuff out of architectures 
   into the core kernel (genirq, gtod, etc.).

	Ingo

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [PATCH for 2.6.28 stable] m68knommu: fix m68knommu defconfig can't build
@ 2009-01-12 11:07         ` Ingo Molnar
  0 siblings, 0 replies; 16+ messages in thread
From: Ingo Molnar @ 2009-01-12 11:07 UTC (permalink / raw)
  To: Sam Ravnborg
  Cc: Paul Mundt, Greg Ungerer, KOSAKI Motohiro, David S. Miller,
	Geert Uytterhoeven, Roman Zippel, Greg Ungerer, linux-m68k,
	stable, LKML


* Sam Ravnborg <sam@ravnborg.org> wrote:

> We just did the exercise with sparc/sparc64 unification and if you 
> forget the few times I broke sparc32 then it went well with only limited 
> problems.

We also had the x86 unification finished in the past year which went very 
well too, so i can only encourage similar efforts.

> One key factor why it went well was that patches were reviewed and 
> applied within a few days whch is why I stresses that the maintainer 
> needs spare time to support the effort.

Yes.

Unification is the Linux meme of the century i guess ;-)

There's two main unification themes:

 - per arch unification (x86, powerpc, sparc

 - cross-arch unification: the moving of useful stuff out of architectures 
   into the core kernel (genirq, gtod, etc.).

	Ingo

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [PATCH for 2.6.28 stable] m68knommu: fix m68knommu defconfig can't build
  2009-01-12 10:59     ` Sam Ravnborg
@ 2009-01-12 11:12         ` Paul Mundt
  2009-01-12 11:12         ` Paul Mundt
  1 sibling, 0 replies; 16+ messages in thread
From: Paul Mundt @ 2009-01-12 11:12 UTC (permalink / raw)
  To: Sam Ravnborg
  Cc: Greg Ungerer, KOSAKI Motohiro, David S. Miller,
	Geert Uytterhoeven, Roman Zippel, Greg Ungerer, linux-m68k,
	stable, LKML

On Mon, Jan 12, 2009 at 11:59:42AM +0100, Sam Ravnborg wrote:
> On Mon, Jan 12, 2009 at 07:44:47PM +0900, Paul Mundt wrote:
> > On Mon, Oct 06, 2008 at 04:20:06PM +1000, Greg Ungerer wrote:
> > > Hi Kosako,
> > > 
> > > KOSAKI Motohiro wrote:
> > > >I guess nobody don't test m68knommu at all last three month.
> > > >Do we still need to maintain this architecture?
> > > 
> > > Yes, we do.
> > > 
> > Any effort to get m68knommu folded in to m68k proper? This might help
> > with some of your bitrot issues.. And likely less work to do in
> > supporting those m68knommu parts that ship with MMUs ;-)
> > 
> > m68knommu is the only one of the mmu/nommu variants left that ships in
> > its own architecture directory rather than being folded in to its parent.
> > It would be good to get rid of it one of these days.
> 
> From the outside it looks like there are indeed a whish to do so
> but both m68k and m68knommu maintainers seems to be busy with other stuff.
> 
> Not that I can think of what is more important than to merge the two
> architectures ;-)
> 
> If I get some spare time one day I have actually planned to try to
> help a little - but that would require an active maintainer..
> 
> We just did the exercise with sparc/sparc64 unification and
> if you forget the few times I broke sparc32 then it went well
> with only limited problems.
> 
> One key factor why it went well was that patches were reviewed
> and applied within a few days whch is why I stresses that the
> maintainer needs spare time to support the effort.
> 
I have some experience with developing a nommu port within an mmu-only
one. If you start some of the legwork on this I can try to chip in some
spare cycles, though ultimately some m68k person will still have to regain
consciousness at some point :-)

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [PATCH for 2.6.28 stable] m68knommu: fix m68knommu defconfig can't build
@ 2009-01-12 11:12         ` Paul Mundt
  0 siblings, 0 replies; 16+ messages in thread
From: Paul Mundt @ 2009-01-12 11:12 UTC (permalink / raw)
  To: Sam Ravnborg
  Cc: Greg Ungerer, KOSAKI Motohiro, David S. Miller,
	Geert Uytterhoeven, Roman Zippel, Greg Ungerer, linux-m68k,
	stable, LKML

On Mon, Jan 12, 2009 at 11:59:42AM +0100, Sam Ravnborg wrote:
> On Mon, Jan 12, 2009 at 07:44:47PM +0900, Paul Mundt wrote:
> > On Mon, Oct 06, 2008 at 04:20:06PM +1000, Greg Ungerer wrote:
> > > Hi Kosako,
> > > 
> > > KOSAKI Motohiro wrote:
> > > >I guess nobody don't test m68knommu at all last three month.
> > > >Do we still need to maintain this architecture?
> > > 
> > > Yes, we do.
> > > 
> > Any effort to get m68knommu folded in to m68k proper? This might help
> > with some of your bitrot issues.. And likely less work to do in
> > supporting those m68knommu parts that ship with MMUs ;-)
> > 
> > m68knommu is the only one of the mmu/nommu variants left that ships in
> > its own architecture directory rather than being folded in to its parent.
> > It would be good to get rid of it one of these days.
> 
> From the outside it looks like there are indeed a whish to do so
> but both m68k and m68knommu maintainers seems to be busy with other stuff.
> 
> Not that I can think of what is more important than to merge the two
> architectures ;-)
> 
> If I get some spare time one day I have actually planned to try to
> help a little - but that would require an active maintainer..
> 
> We just did the exercise with sparc/sparc64 unification and
> if you forget the few times I broke sparc32 then it went well
> with only limited problems.
> 
> One key factor why it went well was that patches were reviewed
> and applied within a few days whch is why I stresses that the
> maintainer needs spare time to support the effort.
> 
I have some experience with developing a nommu port within an mmu-only
one. If you start some of the legwork on this I can try to chip in some
spare cycles, though ultimately some m68k person will still have to regain
consciousness at some point :-)

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [PATCH for 2.6.28 stable] m68knommu: fix m68knommu defconfig can't build
  2009-01-12 10:44     ` Paul Mundt
@ 2009-01-12 13:06       ` Greg Ungerer
  -1 siblings, 0 replies; 16+ messages in thread
From: Greg Ungerer @ 2009-01-12 13:06 UTC (permalink / raw)
  To: Paul Mundt, KOSAKI Motohiro, David S. Miller, Geert Uytterhoeven

Paul Mundt wrote:
> On Mon, Oct 06, 2008 at 04:20:06PM +1000, Greg Ungerer wrote:
>> Hi Kosako,
>>
>> KOSAKI Motohiro wrote:
>>> I guess nobody don't test m68knommu at all last three month.
>>> Do we still need to maintain this architecture?
>> Yes, we do.
>>
> Any effort to get m68knommu folded in to m68k proper? This might help

Some :-)
The header merge is the first step.


> with some of your bitrot issues.. And likely less work to do in
> supporting those m68knommu parts that ship with MMUs ;-)
> 
> m68knommu is the only one of the mmu/nommu variants left that ships in
> its own architecture directory rather than being folded in to its parent.
> It would be good to get rid of it one of these days.

Yep. I think we will likely make some progress on this over
the next few months...



-- 
------------------------------------------------------------------------
Greg Ungerer  --  Principal Engineer        EMAIL:     gerg@snapgear.com
SnapGear, a McAfee Company                  PHONE:       +61 7 3435 2888
825 Stanley St,                             FAX:         +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia         WEB: http://www.SnapGear.com

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [PATCH for 2.6.28 stable] m68knommu: fix m68knommu defconfig can't build
@ 2009-01-12 13:06       ` Greg Ungerer
  0 siblings, 0 replies; 16+ messages in thread
From: Greg Ungerer @ 2009-01-12 13:06 UTC (permalink / raw)
  To: Paul Mundt, KOSAKI Motohiro, David S. Miller, Geert Uytterhoeven,
	Roman Zippel, linux-m68k, stable, LKML

Paul Mundt wrote:
> On Mon, Oct 06, 2008 at 04:20:06PM +1000, Greg Ungerer wrote:
>> Hi Kosako,
>>
>> KOSAKI Motohiro wrote:
>>> I guess nobody don't test m68knommu at all last three month.
>>> Do we still need to maintain this architecture?
>> Yes, we do.
>>
> Any effort to get m68knommu folded in to m68k proper? This might help

Some :-)
The header merge is the first step.


> with some of your bitrot issues.. And likely less work to do in
> supporting those m68knommu parts that ship with MMUs ;-)
> 
> m68knommu is the only one of the mmu/nommu variants left that ships in
> its own architecture directory rather than being folded in to its parent.
> It would be good to get rid of it one of these days.

Yep. I think we will likely make some progress on this over
the next few months...



-- 
------------------------------------------------------------------------
Greg Ungerer  --  Principal Engineer        EMAIL:     gerg@snapgear.com
SnapGear, a McAfee Company                  PHONE:       +61 7 3435 2888
825 Stanley St,                             FAX:         +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia         WEB: http://www.SnapGear.com

^ permalink raw reply	[flat|nested] 16+ messages in thread

end of thread, other threads:[~2009-01-12 13:07 UTC | newest]

Thread overview: 16+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-12-30 10:44 [PATCH for 2.6.28 stable] m68knommu: fix m68knommu defconfig can't build KOSAKI Motohiro
2008-12-30 10:44 ` KOSAKI Motohiro
2008-10-06  6:20 ` Greg Ungerer
2008-10-06  6:20   ` Greg Ungerer
2009-01-12 10:35   ` KOSAKI Motohiro
2009-01-12 10:35     ` KOSAKI Motohiro
2009-01-12 10:44   ` Paul Mundt
2009-01-12 10:44     ` Paul Mundt
2009-01-12 10:59     ` Sam Ravnborg
2009-01-12 10:59     ` Sam Ravnborg
2009-01-12 11:07       ` Ingo Molnar
2009-01-12 11:07         ` Ingo Molnar
2009-01-12 11:12       ` Paul Mundt
2009-01-12 11:12         ` Paul Mundt
2009-01-12 13:06     ` Greg Ungerer
2009-01-12 13:06       ` Greg Ungerer

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.