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 <[email protected]>
CC: Geert Uytterhoeven <[email protected]>
CC: Roman Zippel <[email protected]>
CC: Greg Ungerer <[email protected]>
CC: [email protected]
---
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"
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 <[email protected]>
> CC: Geert Uytterhoeven <[email protected]>
> CC: Roman Zippel <[email protected]>
> CC: Greg Ungerer <[email protected]>
> CC: [email protected]
> ---
> 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: [email protected]
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
> 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.
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.
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
* Sam Ravnborg <[email protected]> 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
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 :-)
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: [email protected]
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