I think this makes a lot of sense. I don't have any strong opinions
about the device naming ... though I'm also coming from a fond Amiga BG
as well :) ... but having a generic abstraction between NFFS in system
flash, FatFS on SD cards over SPI or SDIO, who knows what on SPI flash,
etc., makes a lot of sense.
Pre 1.0 is a good time to get it in there, even if this is really a late
last minute addition.
I really like NFFS but FatFS is still the most useful way to get things
off a device to the outside world with a cheap uSD card, so it would be
nice to have nominal support for that plus SPI flash, at least at the
API level.
K.
On 13/01/17 18:09, Fabio Utzig wrote:
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?
