This have been proposed several times in the past, and always rejected
for what is I think mostly fantasmatic performances reasons.
Though that would fit nicely in the new driver model ;)
The fact is that an indirect function call has a non-negligible cost
on heavily pipelined CPUs like we have nowadays. But on the other
hand, do we do _that_ much perf critical MMIOs ? Most of the really
perf critical IOs are DMA... We could eventually mix that and provide
direct accessors for PCI in addition to generic per-bus "ops"...
Another possibility (that looks saner to me) would be to define that
the IO macros take all a parameter which represents the bus (or rather
the device pointer in the new driver model). Most archs would just
ignore that macro parameter and so have exactly equivalent code as
we have today, but that let archs that feel they need it to actually
use that to go pick the proper access methods for that device.
In all cases, though, I would keep the distinction between {read,write}*
and {in,out}* as there are PCI drivers that will need to mix them.
But I have few hopes for anything like that to ever be accepted
anyway...
Ben.
-
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/