I've been working on patch that adds support for accessing multiple
devices and filesystems on Mynewt (overcoming the current single FS and
"hardcoded" block device per driver). The PR is available here:


This PR is completely functional with some limitations which I'll talk
about below and plan to add on a later PR (given the current one is
already a lot of changes).

The main visible change is that one new package is added which is
responsible to track what disks use what filesystems. I called it
"fs/disk". From a user perspective there is an extra step required which
is a call like this:

    disk_register("mmc0", "fatfs", &mmc_ops);
    disk_register("flash0", "nffs", &flash_ops);

This adds a name for the disk, what FS is used (FS's are registered when
loaded), and what "disk" ops should be used for that named device. The
disk_ops struct is basically an abstraction of possible operations a
disk can do like read/write/erase/etc.

All the fs_* functions where updated to support multiple disks. To
access a file/dir now will required adding the name of the disk as a
prefix like this:

    rc = fs_opendir("mmc0:/", &dir);
    rc = fs_open("flash0:/testfile.txt", FS_ACCESS_READ, &file);

That "mmc0:" and "flash0:" should be the same names that were used when
registering. Of course, one can always use fatfs_open, nffs_open
directly and not need to specify the disk. Also for compatibility
reasons, when only a single FS is used on the project (single FS dep)
the disk prefix is optional (to not break existing code, tests, etc).
But the disk_register must be called nonetheless.

What still needs to be done?

1) Currently FAT is updated to use disk_ops because it only uses
read/write but it should work on other block devices (would, of course,
fail on a real flash that requires erase!). NFFS is still calling the
hal_flash_ functions and should be updated to use the disk_ops interface
(as soon as it has extra calls for erase, etc).

2) Also previously discussed in pvt was the fact that we need to pass
some device context to low-level hal_flash (also mmc_) functions. I
recently wrote a SPI flash driver for AT45DB which will follow the
hal_flash_ interface but it needs to receive an extra context to know
which SPI to use, which configuration, etc. This will probably also add
another parameter to disk_register with the said context struct.

I'll be fixing the above issues on a new PR.

Please review the current PR, add suggestions, etc.

Fabio Utzig

Reply via email to