Messages in this thread | | | Subject | Re: 2.3 wish: integrate pcmcia into mainstream kernel | Date | Thu, 03 Jun 1999 10:59:36 +0100 | From | David Woodhouse <> |
| |
almesber@lrc.di.epfl.ch said: > I've posted this to linux-kernel about two weeks ago, asking for > comments. David Woodhouse responded that there's a group of people > looking at the same issue for certain embedded devices. Their main > concern seems to be space: if you only have a few MB of total storage > for your system, you don't want initrd, cardmgr, insmod, etc.
Actually, my main focus is memory devices - that's on-board flash, SRAM, EMS boards if you still have them, and anything like that. The main aim is to be able to use them for root filesystems.
We're developing a generic subsystem for handling MTDs (Memory Technology Devices), into which you plug a low-level driver for your specific hardware, and all the higher-level functions such as FTL filesystems are provided for you by the upper layers.
David Hinds has already implemented something very similar to this in his PCMCIA code, and the intention is to make them compatible enough that future PCMCIA code can use our new MTD subsystem rather than its own.
My intention wasn't to bypass the PCMCIA code for _PCMCIA_ devices, but to abstract the MTD subsystem so that it can be used with non-PCMCIA devices as well as PCMCIA.
However, it should be fairly easy to convert your 'enabler' to a low-level MTD device module, which can be distributed as one of the device drivers for the MTD subsystem. That way, people can choose whether to use it or the full-blown PCMCIA implementation.
Some way of using your enabler at boot-time, and then passing control to the 'real' PCMCIA implementation, might be appropriate too.
Work on the MTD subsystem hasn't been moving very fast - we have two versions, both available in ftp://imladris.2001ad.net/pub/mtd/ - we're intending to merge them and make sure they still provide the functionality that the PCMCIA code wants. But I've been concentrating on this poxy Disk-On-Chip2000 from M-Systems, and haven't had any time for it.
On the subject of the Disk-On-Chip - the best advice seems to be 'use something else'. M-Systems are being extremely awkward about support, and the device appears to require sequential reads of bytes from a single byte-wide window to the flash - not something you want to use if you're at all interested in performance. But I'm struggling on with it - if you're stuck with a Disk-On-Chip, we should be able to use it soon anyway, but just don't expect it to be much better than their binary-only drivers.
---- ---- ---- David Woodhouse David.Woodhouse@mvhi.com Office: (+44) 1223 810302 Project Leader, Process Information Systems Mobile: (+44) 976 658355 Axiom (Cambridge) Ltd., Swaffham Bulbeck, Cambridge, CB5 0NA, UK. finger dwmw2@ferret.lmh.ox.ac.uk for PGP key.
- 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/
| |