Hi,
sorry to join in so late in this thread, but I think I should bring the
following to your attention:
Someone (David, I think) said that IA64 was handling 32-bit controllers
fine. To my experience, that depends strongly on the drivers.
At least for aic7xxx, it is not the case (I have documented the
related crashes on the linux-ia64 mailing lists during the last two
months). The driver is simply eating up buffer space in such vast amounts
that it freezes the software IO-memory management even at very moderate
load (you can use the "old" driver instead, but this doesn't look like a
long-term solution).
After some discussion, Justin Gibbs announced that he'll implement 39-bit
DMA addressing in the aic7xxx driver, and it appeared that this was
pretty much the only viable solution to make the "new" aic7xxx driver work on
IA64. I haven't looked at his new code yet, but I assume he's using the
IA64 approach.
It is likely that this will happen for other drivers as well, especially
those that need a lot of buffer space for good performance. Thus the IA-64
API will probably emerge as a matter-of-fact standard, and if something
better is to replace it, I think it should be decided upon quickly, so
that driver maintainers (and IA64) can adopt to it before everything has
to be written (and debugged) twice.
Regards,
Martin
--
Martin Wilck <[email protected]>
FSC EP PS DS1, Paderborn Tel. +49 5251 8 15113
Martin Wilck writes:
> Thus the IA-64 API will probably emerge as a matter-of-fact standard
It is, and can only be, an IA-64 hack, not an API. This hack simply
cannot work at all on any 32-bit platform. Only an API using page +
offset + len triplets can work successfully on all platforms.
And I think the new aic7xxx driver can be made to work just fine, and
the fact that the old aic7xxx driver is able to be nice to the IO
mapping allocator pool (AND get decent performance) is evidence of
this. Really, what I hear sounds like merely a cop out.
Later,
David S. Miller
[email protected]