Ben LaHaise writes:
> Sorry, but that's not a good enough answer if 2.5 takes the same 2 years
> that 2.3 took. Define the API so that people can at least write their
> drivers to the spec, or else suffer the consequences of people doing their
> own thing.
Shit happens Ben. One has to draw the line somewhere.
Sure, once 2.5.x has the interfaces, we'll add the "dummy" ones
to 2.4.x, but only then. I don't even know %100 how I want the
damn thing to look yet.
There are so many issues with 64-bit DAC support, that many of
the people whining in this thread have not even considered, and
these very issues will be what shapes the eventual API to use.
For example. I have IOMMU's on my machine, there is no real need to
use 64-bit DAC in %99 of cases. In fact, DAC transfers run slower
because they cannot use the DMA caching in the PCI controller.
How do you represent this with the undocumented API ia64 has decided
to use? You can't convey this information to the driver, because the
driver may say "I don't care if it's slower, I want the large
addressing because otherwise I'd consume or overflow the IOMMU
resources". How do you say "SAC is preferred for performance" with
ia64's API? You can't.
This, almost with several other issues, need to be considered and
handled by whatever API you come up with. If it does not address
all of these issues somehow, it is unacceptable.
Later,
David S. Miller
davem@redhat.com
-
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/
This archive was generated by hypermail 2b29 : Sat Jun 30 2001 - 21:00:20 EST