[lkml]   [1999]   [Mar]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: 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. ;-)


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:50    [W:0.022 / U:23.284 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site