Re: [PATCH] Updating our sn code in 2.6

[Christoph Hellwig]

On Sun, Dec 28, 2003 at 10:32:51AM -0600, Colin Ngam wrote:
> > the now almost legacy SHUB/PIC based Altixens?  Well, even if SGI does this
> 
> SHUB/PIC based Altixens are not Legacy in any form shape or manner.  I expect
> these IO Chipsets to drive Altix for the foreseable near future ..

Well, it looks like TIO is replacing it soon, doesn't it?


> Please do not question my resolve to drive us towards this direction.  Things can
> always change, but I am heading this direction.

Well, again talk is cheap, if you show the code this whole discussion
would be avoid.  I've done my part of showing the code and the only thing
I get in reply is bad flames and random obsfucations to break that code.

> architecture.  That is not a problem at all.  For ia64 Altix line, we want
> to follow what's being done on other ia64 platform.  Is this not the
> right approach?  You yourself had mentioned above that this is the
> way to go?

Again, I'd be more than happy if you moved that code to the PROM.  But as
long as we have code in the kernel to deal with that hardware different ports
should share it.  And as mentioned above I have that strong feeling that
for the first generation Altixens this is never going to happen.  Of course
I'd be more than happy to be proven wrong.

> This code sharing will not be possible when we do all of our initialization
> in System BIOS, just like every other ia64 platform.

Again, if you do that I'd be more than happy.  But as long as we need that
code in the kernel it should be done properly.

> Moreover, the ia64
> Altix line does not support Bridge/Xbridge chipsets and we do not want
> to be burdened by these legacy code as we move forward with the ia64
> product line.

Guess what, the current iommu code has exactly three lines of code that
make sense only for bridge.  Not to mention that I'll have no problem with
maintaining all that code, so you don't have to maintain more but rather
less code.  (In a double sense, given that the new code is also much
smaller despite support for the older revisions)

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/