Rene Herman wrote:That could be true if outb_p were used only in architecture dependent code, but it's not. It's used in drivers that are supposed to run on all sorts of platforms. Why does a megaraid controller need delays on i386 but not on Sparc, PowerPC, Alpha and others? Is it buggy on most platforms, or just unnecessarily slow on Intel? You misunderstand. A delay can be counted in bus cycles. It's most commonly a zero delay. Only in the minority of architectures is it otherwise. If a delay is needed, then put one in, but don't put in a paper promise that's more likely to be ignored than observed. Plenty of doubt has been expressed as to whether _p is widely used without need. Not surprising since it has such a vague specific meaning. One could say, Linux on i386 is liberally sprinkled with needless delays. I suppose it has the advantage that Microsoft will be hard pressed to catch up when finally we remove them. :-) I really prefer accurate code, but I'm also pragmatic and realise that it's far too much work to fix this any time soon. But if it were to be fixed, then perhaps _p would take an additional parameter, measured in cycles of delay. --
| Greg Kroah-Hartman | [PATCH 004/196] Chinese: add translation of SubmittingPatches |
| David Newall | Re: Slow DOWN, please!!! |
| Andrew Morton | Re: Linux 2.6.21-rc4 |
git: | |
| David Miller | [GIT]: Networking |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
| Jarek Poplawski | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Dale Farnsworth | Re: [PATCH 01/39] mv643xx_eth: reverse topological sort of functions |
