Messages in this thread |  | | | Date | Fri, 5 Mar 1999 22:34:42 +0100 (MET) | | From | Gerard Roudier <> | | Subject | Re: user space writel() etc. in 2.2.2 |
| |
On Fri, 5 Mar 1999, Vassili Leonov wrote:
> On Fri, 5 Mar 1999, Alan Cox wrote: > > OK, finally I am enlightened (by Alan and others). The story is that > there is no portable solution for IO memory acces in current Linux. It is > platform dependent in a non-trivial way: > > > On Fri, 5 Mar 1999, Alan Cox wrote: > > There really isnt an easy one > > > > ARM - no cache coherency
No cache coherency leads to heavily broken drivers and thus O/Ses and requires some complexity we probably want to avoid, at least I do. Great stupidity, in my opinion.
> > Alpha - offset PCI mapping. PCI I/O space is mapped in strange ways > > varies by platform
Paranoia of CPU optimisation for only having to deal with 32 bits and 64 bits. Since MMIO is only usable with some flush of CPU buffers, designers could allow 8 bits and 16 bits quantities for MMIO without addressing weirdnesses and without complexifying CPU optimization stuff. IMO, architects were not quite aware of how a usable IO sub-system for PCI should be.
> > PMac - PCI bus is endian swapped in hardware
This is pretty useless and highly stupid, IMO for the following reasons:
1 - This only can speed-up a bit IOs from the CPU and the PCI BUS is slow compared to CPU. Having some instructions that deal with endian-ness does suffice. 2 - The right way to do IOs with PCI is to DMA from the device and certainly not to stall the CPU and to use small bursts or no bursts at all. Still guys who should have learnt how IOs must be handled.
> > x86 - Sane (well its the reference bus) > > Sparc64 - Basically sane - again PCI I/O space is mapped as memory
This one has also some design weirdness regarding PCI.
It seems that only Intel has been able to provide a reasonnable PCI BUS implementation. But, on the other hand, they donnot seem to be capable to provide real CPUs (I mean 64 bit) in time. ;-)
Regards, Gérard.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
|  |