So what? I frankly don't care what alpha or any platform happens to
do. The Documentation/DMA-mapping.txt document says absolutely
nothing about these routines ever failing nor what a failure value
would be. If you ask David Mosberger and the ia64 people, the PPC
folks, or even HPPA port team, they will all show no surprise when
told that these routines may not fail. I talked to them, along with
Richard, about this issue at length when the DMA stuff was put
together. And it was agreed upon that the routines will not allow
failure in 2.4.x and we would work on resolving this in 2.5.x and no
THIS DMA-mapping.txt document is the specification of the behavior of
these DMA interfaces, and the driver author may only assume the
behavior described in that document.
If Alpha does something different, that's a feature.
> About the pci_map_single API I'd like if bus address 0 would not be the
> indication of faluire, mainly on platforms without an iommu that's not
> nice, x86 happens to get it right only because the physical page zero is
> reserved for completly other reasons. so we either add a err parameter
> to the pci_map_single, or we define a per-arch bus address to indicate
> an error, either ways are ok from my part.
I'm more than happy to add the per-arch define (which would be zero
on all platforms right now, so this exercise is %100 academic :-)))))
But I will NOT add the change that the pci_map_*() interfaces may
fail in 2.4.x, this is an unacceptable API change. Reasons are
starting with the scsi layer issues Gerard mentioned, and I knew
about this kind of crap when I designed the API. We can work on a
failure mode for this stuff, but it is 2.5.x material, no sooner.
David S. Miller
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to firstname.lastname@example.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/