Code size report:

   bare-arm:    +0 +0.000% 
minimal x86:    +0 +0.000% 
   unix x64:  +208 +0.026% standard[incl +32(data)]
      stm32:   +56 +0.014% PYBV10
     mimxrt:   +24 +0.007% TEENSY40
        rp2:   +40 +0.012% RPI_PICO
       samd:   +16 +0.006% ADAFRUIT_ITSYBITSY_M4_EXPRESS

Codecov Report

Attention: 2 lines in your changes are missing coverage. Please review.

Comparison is base (16c6bc4) 98.36% compared to head (5131dbd) 98.35%.
Report is 12 commits behind head on master.

@@            Coverage Diff             @@
##           master   #13470      +/-   ##
==========================================
- Coverage   98.36%   98.35%   -0.01%     
==========================================
  Files         159      159              
  Lines       21088    21090       +2     
==========================================
  Hits        20743    20743              
- Misses        345      347       +2     

☔ 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)

This is an automated heads-up that we've just merged a Pull Request
that removes the STATIC macro from MicroPython's C API.

See #13763

A search suggests this PR might apply the STATIC macro to some C code. If it
does, then next time you rebase the PR (or merge from master) then you should
please replace all the STATIC keywords with static.

Although this is an automated message, feel free to @-reply to me directly if
you have any questions about this.