Now thinking more thoroughly about this I think I arrived at some better
semantics.

First one correction from what I previously said: since nffs is still
hardcoded to hal_flash, using only nffs would not require a call do
disk_register (because no disk_ops is required!).

So, my idea is changing disk_register semantics to be used by "disk"
drivers instead of by the user app. A disk driver, like flash/mmc/etc,
would then register itself (like FS's do) with:

    disk_register("flash", &flash_ops);
    disk_register("at45db", &at45db_ops);
    disk_register("mmc", &mmc_ops);

The user app will then call "disk_mount" to make this disk available
like this:

    disk_mount("flash0", "nffs", "flash", &flash_device_specific);
    disk_mount("flash1", "nffs", "at45db", &at45db_device_specific);
    disk_mount("mmc0", "fatfs", "mmc", &mmc_device_specific);

Using the fs and disk driver names. This would be a lot more intuitive
for people with unix background. Also an complimentary "disk_unmount"
can be added, of course which would be interesting for shell usage with
devices that support hot disk swap.

What do you think?

Fabio Utzig

On Fri, Jan 13, 2017, at 08:43 AM, Fabio Utzig wrote:
> Hello,
> 
> 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:
> 
> https://github.com/apache/incubator-mynewt-core/pull/158
> 
> 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.
> 
> Cheers,
> Fabio Utzig

Reply via email to