Re: Memory technology devices.

David Hinds (dhinds@hyper.stanford.edu)
Wed, 17 Sep 1997 14:19:23 -0700


On Wed, Sep 17, 1997 at 03:40:31PM +0100, David Woodhouse wrote:
>
> So: Would anyone, especially those involved with the PCMCIA code that I've
> either stolen or intend to replace, like to request changes to the way I'm
> doing it, before I start tidying it up and trying to make it fit for release?

I think this is a complicated issue and requires some serious thought
(which maybe should have gone on before writing any code, rather than
after). Looking at what you've done, I'm not sure what would be
gained by adapting the PCMCIA drivers to use this interface. There
would still need to be different MTD's for different cards that have
the same underlying memory technology (i.e., PCMCIA and ISA flash
cards). And (I think) different higher level drivers as well. I
think the fundamental problem is that you've picked the wrong level of
abstraction for your API.

The PCMCIA specification for the MTD interface (which is what I've
implemented in the Linux PCMCIA package) has the following structure:

User mode
Client driver(s)
Bulk Memory Services
Memory Technology Driver(s)
MTD Helper Services
Hardware

Now, "Bulk memory services" and "MTD helper services" are actually
both implemented in the PCMCIA Card Services module, but they have
mostly independent API's. The Memory Technology Driver is supposed to
be more or less insulated from differences in hardware implementation
(i.e., how the memory card is paged into the host address space, how
status is monitored, etc) by the helper layer.

In your proposed system, we have:

User mode
Client driver(s)
MTD support driver
Memory Technology Drivers(s)
Hardware

where the "MTD support driver" is in mtd.c, and provides a "raw"
memory device, and other client drivers stack on top of this module.
Of course, in this system, an MTD doesn't have to talk directly to the
hardware: a PCMCIA-aware MTD could pass requests through the MTD
helper services. However, this sacrifices the benefit of the extra
layers of abstraction of the PCMCIA system, because non-PCMCIA devices
don't have the same set of driver components. For example, your flash
card driver is ISA specific: it effectively merges the MTD with the
MTD helper functions. The MTD helper abstraction is just as important
if not more important than the higher level layers.

I'm afraid that you're probably not going to like this, but I have a
completely different suggestion for how to go about implementing a
more "generic" MTD system that would be inclusive of PCMCIA as well
other types of memory devices.

Currently, the MTD Helper interface I've implemented is somewhat
incomplete, because for purely PCMCIA applications, I only coded what
I had to. It is "impure" in the sense that the existing MTD's also
make direct Card Services calls. This interface could be fleshed out
by adding one or two new services, and implementing the unimplemented
ones, so that an MTD could rely entirely on this interface and not
call Card Services directly. Then, Card Services could become just
one of several providers of MTD helper support. The existing bulk
memory services code in Card Services could be broken out into a
separate module (probably not too difficult, since they are already in
a separate compilation unit), which would provide a generic interface
for MTD-supported PCMCIA as well as non-PCMCIA devices. There are
still a number of tricky issues to be dealt with, such as how PCMCIA
events would be passed through the various layers.

I think the PCMCIA MTD specification is, over all, a good starting
point for thinking about how to do this in a general way, and I would
much rather keep the same structure rather than reimplement the same
functionality with a completely new API.

-- Dave Hinds