Re: [PATCH] Updating our sn code in 2.6

[Colin Ngam <cngam@SGI.com>]

Christoph Hellwig wrote:

> 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.

Hi Christoph,

I do not believe I have sent any "bad flames" or any flames, at all to you
regarding this issue.  That would just be rude and bad culture.  It is just not
that way I conduct business as we all have so much to contribute.

I am just trying to share with you our plans.  That's only fair to you.

Thanks.

colin

>
>
> > 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)