# MTD internal API documentation - overview

## Structure

The MTD system is divided into two types of module: "users" and "drivers".

Drivers are the modules which provide raw read/write/erase access to physical memory devices.

Users are the modules which use MTD drivers and provide a higher-level interface to user-space.

We currently have four 'user' modules available: FTL, NFTL, JFFS and MTDBLOCK. FTL and NFTL both provide a pseudo-block device on which a 'normal' filesystem is placed. JFFS is a filesystem which runs directly on the flash, and MTDBLOCK performs no translation - just provides a block device interface directly to the underlying MTD driver.

Just because I use the word 'module', it doesn't mean that these have to be loadable modules. You can link them statically into your kernel.

## Writing a driver module

Instructions for writing a driver are very simple:

- Allocate and populate a `struct mtd_info` with information about your device, and pointers to your access routines.
- Register it by calling `add_mtd_device`

Oh yes - you have to actually write the access routines too, which have to conform to the rules.

## Writing a user module

This is only slightly more complex:

- Write a pair of `notifier` `add` and `remove` functions, which will be called whenever a driver is added to, or removed from, the system, respectively.
- Register them by calling `register_mtd_notifier`

This ought to call your notifier function immediately for all drivers which are already present in the system. But it doesn't yet. Currently, drivers scan through calling `get_mtd_device()` to find previously-loaded drivers. This is bad and will be fixed soon.

$Id: overview.html,v 1.1 2000/03/30 10:38:14 dwmw2 Exp $