ports/rp2: Add a means to set mass-storage filesystem label - #13470

Code size report:

   bare-arm:    +0 +0.000% 
minimal x86:    +0 +0.000% 
   unix x64:  +192 +0.022% standard[incl +32(data)]
      stm32:   +56 +0.014% PYBV10
     mimxrt:  +552 +0.148% TEENSY40
        rp2:   +72 +0.008% RPI_PICO_W
       samd:   +16 +0.006% ADAFRUIT_ITSYBITSY_M4_EXPRESS
  qemu rv32:    +0 +0.000% VIRT_RV32

Codecov Report

Attention: Patch coverage is 0% with 1 line in your changes missing coverage. Please review.

Project coverage is 98.56%. Comparing base (b725c26) to head (f8b35df).

@@            Coverage Diff             @@
##           master   #13470      +/-   ##
==========================================
- Coverage   98.56%   98.56%   -0.01%     
==========================================
  Files         169      169              
  Lines       21948    21949       +1     
==========================================
  Hits        21633    21633              
- Misses        315      316       +1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

I'm not sure that this is the best way to do it, because it adds a method, code size, and differs to other Vfs filesystems that don't support a label.

How about instead copy the way the stm32 port does it, have a MICROPY_HW_FLASH_FS_LABEL that can be configured for any port, and in extmod/vfs_fat.c whenever f_mkfs() is called it also calls f_setlabel(..., MICROPY_HW_FLASH_FS_LABEL)? Then the label will always be set to the port-defined value whenever a FAT filesystem is formatted.

As it stands, you're probably right and I'll refactor this PR to fix the omission without addressing our specific use-case-

I've got a fork with some minimal changes that allow USB Mass Storage mode builds to expose two filesystems (currently hard-coded, but then the whole USB MSC thing is a bit of an exception to the do-everything-USB-in-Python goal at the moment).

In our - admittedly quite contrived - demo case, these two filesystems have distinct labels.

The conceit is that we can have one filesystem that's writable from MicroPython, and one that's writeable from the host and use the formere as a means to support logging, saves, config changes and so forth while code is written into the latter from the host. Of course this is all highly experimental but it works and suggests there might be scope for some more esoteric FAT/MSC builds if we find the experience... tolerable. I am keenly aware of all the problems with filesystem syncing across multiple hosts from my tinkering with PiratePython (a CPython RAMdisk for Pi Zero).

It might be that MicroPython is unconcerned with the slippery slope that is FAT/MSC and the answer is for us to build our own C module to implement this functionality (ala the Factory Reset style of some ports). I'm happy with that.

(on the off chance anyone wants to replicate this dual FS weirdness, diff here - master...pimoroni:micropython:feature/multi-msc)

I have rebased/pushed this because I'm experimenting with FAT again.

I believe the multiple-filesystems issue still presides, since as of 6aa3c94 you can select a portion of RP2s flash on which to create a filesystem, and potentially create as many filesystems as you like.

That makes use of MICROPY_HW_FLASH_FS_LABEL a little contentious, since all creates vfat filesystems would have the same name with no means of overriding it.

Perhaps a label argument could be added to vfs.VfsFat(), and other filesystems that support labels? Defaulting to MICROPY_HW_FLASH_FS_LABEL?

Edit: I should note that my current focus is on a single filesystem with a boot-time switch to select between mass-storage and runtime modes, avoiding any read/write conflicts between the host and device. So the MICROPY_HW_FLASH_FS_LABEL would work fine for that. I am - perhaps unnecessarily -considering potential future complications.

Commit 390390e made it so the label is set to MICROPY_HW_FLASH_FS_LABEL when formatting the filesystem via VfsFat.mkfs().

I can see how it would still be useful to allow Python to set the label (eg for multiple filesystems with different labels). That could either be done as per this PR (a new method, VfsFat.label()) or a new kwarg to VfsFat.mkfs(..., label). With a new method, it might also be useful to be able to get the label, eg no args would get it vfs.label().

Whatever is added, it's going to cost a bit. But I guess that's just the cost of having good filesystem support.

I discovered the hard way that changing/writing the filesystem label on boot will result in a corrupt filesystem more often than not, so making it part of mkfs makes a lot of sense. It's otherwise not super obvious that it changes the FAT (well in hindsight maybe it is, but it wasn't to me) and would cause issues if there were sudden power loss (like tapping reset twice by accident).

I've since switched to preparing a pre-loaded filesystem up front and setting the label "offline" as such, so it's already set when the board boots.

Anyway TLDR I think setting label during mkfs is safer than a label method on an existing filesystem object.

Anyway TLDR I think setting label during mkfs is safer than a label method on an existing filesystem object.

OK, sounds good.

Then I'll close this PR and in the future someone can implement the mkfs(..., label) argument.