On Monday 18 May 2009, FUJITA Tomonori wrote: > > NACK'ed, sorry. I had no idea how hard it would get to fix a simple allyesconfig build error. This is the third time that a new approach to getting ATA to build on all platforms is gets a NAK... > - these idndef tricks are really ugly and wrong. > - these functions are not generic at all. I was trying to do two things at once: - provide a default implementation for each function that an architecture can override, therefore the #ifdef magic. - Have a minimal working implementation of the API that at least makes sense for architectures that do not support DMA, but want to share some of the code. Ten of the existing architectures simply try do a linear mapping, and that should easily be possible in a generic way not too different from what I posted. Would you agree to a patch that works with the same code on e.g. arm, microblaze, mn10300 and sh and uses only a few #ifdefs? > - it's confusing to have two ways to handle this issue; > dma-mapping-broken.h and dma-mapping.h. We actually already have three ways to handle this right now: - dma-mapping-broken.h: only used on Sun3 m68k, i.e. not interesting any more, plus it does not solve the question of how to build ATA drivers on architectures without DMA. - selecting NO_DMA: This works fine for everything except ATA. All other drivers using dma-mapping.h either depend on HAS_DMA or sprinkle their files with #ifdef. - adding a bogus dma-mapping.h: cris, um and microblaze currently set HAS_DMA but add a dma-mapping.h that allows stuff to compile but cannot actually work. I think that dma-mapping-broken.h has served its purpose and we should now have two implementations in asm-generic, the one you posted recently for ia64, x86, parisc, powerpc and sparc64 and one for all architectures that only have linear mappings. The version I posted is certainly not generic enough for those, but I can keep improving it. Arnd <>< -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
