Re: [PATCH] Updating our sn code in 2.6

[Christoph Hellwig <hch@infradead.org>]

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?