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.