[lkml]   [1999]   [Mar]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectIdeas for abstracting driver IO from bus implementation?
    This is sort-of a PCMCIA specific issue at the moment, but could be
    thought of as a more general kernel driver issue, so I thought I'd put
    it out for comments, to see if anyone [Alan??] has any clever thoughts.

    On a normal x86 (or PowerPC) laptop, PCMCIA bridges are designed to
    map cards directly into the host IO and memory spaces at arbitrary
    addresses, and a stock ISA or PCI driver generally doesn't care if it
    is talking to a normal device or a device on a PCMCIA card. However,
    there are a number of PCMCIA architectures in which cards are not
    accessed through the same abstractions used to access other types of
    system devices. For example, there are SCSI-to-PCMCIA adapters,
    parallel-to-PCMCIA adapters, SBUS-to-PCMCIA adapters, and various
    specialized bridge chips that sit on the system bus but do not allow
    PCMCIA devices to be arbitrarily configured to mimic the corresponding
    type of directly connected system device.

    In the official PCMCIA way of doing things, say in the Windows world,
    these each require a dedicated Card Services stack, and client drivers
    that know about how a particular bridging system works. There is some
    support for an abstraction layer for memory cards, but that's all, and
    I don't know if it is even implemented by any existing software.

    So, I'm wondering how to deal with this in some clean fashion. I've
    had a whole bunch of inquiries about this in the past month or two,
    for all sorts of unusual hardware setups (ARM embedded designs, Sparc
    platform, Amiga, etc). And I think it would be nice to handle all of
    these cases.

    My thought is to have a socket driver publish a set of entry points
    for primitive IO operations: effectively, replacements for readw,
    writew, inb, outb, and friends. These would be passed out to any
    client driver for that socket. Solaris has an equivalent sort of
    abstraction layer, where you make a DDI call to indirectly access any
    device register. I'm wondering if such an abstraction layer would be
    of any use for other types of Linux drivers, and if so, how I should
    design my API to make it as broadly useful as possible.

    One option is to do it mostly through macro trickery, and make all the
    usual Linux calls map to other things behind the scenes. That's not
    completely trivial because different sockets in the same system might
    have different access methods. I'd like to have the option of
    compiling a driver for native or indirect access methods from the same
    source code, but this probably means replacing inb(port) with, say,
    read_io_byte(sock_handle, port) (or sock_handle->read_io_byte(port),
    or io_handle->read_byte(port)), and having a header file that could
    collapse this to inb() based on a configuration option.

    So I guess my questions are, do people see uses for this sort of thing
    for non-PCMCIA drivers? Should I try to implement something like a
    stripped-down Solaris DDI layer that isn't PCMCIA-centric, or should I
    not worry about generality? In either case, this will cause trouble
    with code sharing between PCMCIA and regular Linux drivers: for the
    scheme to work, various standard Linux drivers would need to be
    retooled to support indirect device accesses. I guess the 8390 driver
    has already had something like this hacked in for a special case, so
    there's some precedent for it. Any comments?

    -- Dave Hinds

    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.021 / U:45.836 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site