Thanks for working on this! I'm just back from the road, so it may take me some time to review the changes in detail, but I think the code size increase is worth it to support such a feature.

So, I had more detailed look finally, and this looks very good. Yes, this adds some code, but for very useful functionality. I see that various corner cases are handled, so I'm +1 to merge this ASAP unless big issues are known.

Yes, this adds some code, but for very useful functionality.

Well, from my point of view there was not a full discussion about this functionality. I still er on the side of keeping the VFS simple (ie no mounting at root) because 1) this VFS code needs to go in every port that wants to have compatible filesystem behaviour, even ports that have little ROM (eg possibly microbit); 2) having this feature will increase differences between stmhal/pyboard and esp8266.

this VFS code needs to go in every port that wants to have compatible filesystem behaviour, even ports that have little ROM (eg possibly microbit);

Well, we do due diligence on keeping the code size small. Sometimes however, in the sake of cross-port generality in a very user-visible places, we need to go for a compromise like that.

having this feature will increase differences between stmhal/pyboard and esp8266.

Having this feature first of all decreases differences between Unix and bare-metal ports, and that's very important win. It has various implications, e.g. suitability of MicroPython to be a real "OS" like environment, without very crude compromises, like like of a true root of filesystem.

Otherwise, that feature isn't going to increase differences short term, because esp8266 already had filesystem mounted at /. And longer term, next version of uPy is 1.9, then 2.0 is on the horizon, and that will be a great opportunity to leave old "pyb" baggage behind. But for that to be truly viable, we need to have a truly common featureset, and it should account for basic requirements of bigger systems too (that being not that they're bigger, but that saving 100 bytes while subjecting users to non-least surprise regarding filesystem behavior isn't a good compromise).

Having this feature first of all decreases differences between Unix and bare-metal ports,

I can guess what this means but please can you explain in detail what you actually mean by this.

that will be a great opportunity to leave old "pyb" baggage behind.

This is not something I want to do. And I anyway think that the way stmhal does the filesystem is "better" for embedded applications: you have a set of filesystems, none of which are particularly suited to mounting at root because at any given time none of them may be available. Eg flash may not be available if you turn that feature off, sd not when there's no SD card, you may have a romfs for a recovery mode, a ramfs at certain times to do fast filesystem access, extflash for external SPI when that is powered up, etc. So the official suggestion that I'd like to make to users is to have a blank root FS, and then you mount devices at a mount point in the root when you use said device. You chdir to the mount point that you want to use as the "current" working FS, and then add to sys.path any locations on other mount points that you want to use as sources for libraries.

, but that saving 100 bytes

The current PR is up to 150+ and last I looked at it I was still finding corner cases with the root filesystem not behaving as expected.

I can guess what this means but please can you explain in detail what you actually mean by this.

But we discussed all this already. Doing it the natural way, by allowing root to be mounted on root, we can switch Unix port to VFS implementation, where it interfaces to the underlying POSIX FS. Doing so will allow to have a common FS handling scheme for all ports, and thus consistency and generality.

This is not something I want to do.

No problem, but please don't make pyboard be a brake on MicroPython progress ;-)

And I anyway think that the way stmhal does the filesystem is "better" for embedded applications

I certainly agree. But what's "better" for adhoc limited embedded application is a toy-like, random arbitrary restriction for real-world usage. The litmus test would be a question "Can MicroPython replace a small system based on Linux and Linux shell?" And while MicroPython offers much wider and more expressive programming environment, such arbitrary restriction with FS handling turn it down to be, again, "toy-like". Why we went all this way just to purposedly cripple it in a pretty user-visible place in the end? Let's make it up to the real world!

Eg flash may not be available if you turn that feature off, sd not when there's no SD card, you may have a romfs for a recovery mode, a ramfs at certain times to do fast filesystem access, extflash for external SPI when that is powered up, etc.

That's very niche, peculiar case I'd say. Usually, there's a "default" filesystem, if a user disables one type of it, they should set another as such, as the most obvious solution.

So the official suggestion that I'd like to make to users is to have a blank root FS, and then you mount devices at a mount point in the root when you use said device.

Well, your code allows to have "unmounted" root, but mount VFSes beneath it, right? Then that scenario will work, it's just not natural comparing with how we have it on the rest of systems around us. So, it may confuse users (as it doesn't follow the principle of least surprise), and I don't understand why you hold onto that.

and then add to sys.path any locations on other mount points that you want to use as sources for libraries.

But you see, sticks already pop up from the ducktape of your solution. That's not how people usually do it! There's a well-known by convention path, and people usually mount something to make user it's available, not other way around - it may seem easier to change paths, but multiplies by time and space, that leads to configuration hell. And natural standard path is "/lib" (not the whole filesystem just for libs of course!)

The current PR is up to 150+ and last I looked at it I was still finding corner cases with the root filesystem not behaving as expected.

Good. That's why we're conservative on adding features which could be not added. 300 bytes, 1K is ok to make it real-world useful. Otherwise we can go straight to CP/M times of single flat FS - indeed, most of esp8266 systems have just that "and nobody even complains". So again, why did we go such a long way to just stop one step away from making it real?

Forgot to add another comment I had in mind during previous review:

And I don't even propose to make support for mounting at "/" to be configurable - doesn't make sense. Instead, we should support option if having just one VFS mounted, and then it will be mounted - tadam - at root, as an obvious way to keep the code the most minimal, which is the requirement here. So, all pieces of the puzzle fall into their place by following standard well-known rules of handling file systems.

Ok, I'm happy that we had enough discussion on this and I guess it's good to try and be general in this case. Merged in c9a3a68 up to e62235f

The tests that were added are still WIP, and for the moment just serve to check basic behaviour. All the VFS tests need to be revisited anyway and possibly refactored.

Thanks!