Messages in this thread | | | Date | Sun, 28 Dec 2003 14:44:15 +0000 | From | Christoph Hellwig <> | Subject | Re: [PATCH] Updating our sn code in 2.6 |
| |
On Fri, Dec 26, 2003 at 01:42:03PM -0600, Colin Ngam wrote: > Hi Christoph, > > Yes I agree. However, keep in mind that we are following the ia32/ia64 > way of getting platforms initialized, via ACPI etc. What you see as > drivers code in sn/io will probably not exist anymore. All initialization > and configuration will be done at the System BIOS level and information > passed down to the Linux Kernel via ACPI. This will take away much > code in the kernel.
Well, I've heard this a few times now and life would definitly be simpler if you're going down that route. OTOH we all know talk is cheap and code speaks, and do you really expect SGI to invest money into doing that for the now almost legacy SHUB/PIC based Altixens? Well, even if SGI does this some day it won't really hurt us to get the code in shape first even if it's only use on MIPS IP27/IP35, wouldn't it?
> We believe that all that will be left in sn/io directory maybe files dealing with > DMA mappings(IOMMU).
That's one of the candidates that really should be shared with IP27 and the once someone does them the IP30 and IP35 ports. Really, the basic dma mapping code is the same for Bridge/Xbridge/PIC/TIOCP so we should have one driver. And once all the IRIX I/O infrastructure depency is ripped out that part of pcibr is rather self-contained. I can send you my latest variant of the dma mapping code if you want, but due tue all that stupid renaming of structure and macro names it won't compile in your tree. See why I _really_ _really_ dislike that silly renaming? It breaks all those nice efforts for code-sharing without any gain.
Even IRIX TOT uses the 'old' names, so what is the point of renaming them? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |