Hi Michael,

Sorry for the delay, I've been quite busy with work these past few days.

Yes, it sounds good, I'll keep it on a separate repo until it's actually more or less mature.

As for your questions,

1) I'm planning to make this read-write, but most importantly, I want it to be solid. If I can't reach write support, it's okay, since it's just a stretch goal.
My idea was to get solid read-only support, as it's naturally the most important part of a firmware filesystem driver (and as far as I know, there are not many
EFI applications/bootloaders that write to the filesystem). If I get the desired solidity and unit tests going, I want to make it write-capable too.

2) Although I'd love to avoid journaling, which is a matter I'm not too familiar with, I'm not entirely sure what simplifications may be done because for one,
what happens if the power cuts during a write? It's unclear to me how a FW filesystem driver might work on a damaged filesystem like that, since it's not at all similar to an OS,
which usually can do some sort of 'fsck' invocation to repair a filesystem before it's mounted. Is the firmware essentially unable to boot to those partitions until
someone gets a recovery drive of some sort that has a 'fsck' on it? I hope the FAT32 code has some answers for me, but I haven't had the time to go look at it that closely just yet.
It might be that the chance of this happening is minimal, but that doesn't sit right with me.

Also, one question: Does firmware code need the usual synchronization primitives (only spinlocks in this case, I would assume) or is it just assumed that it's a single threaded
environment? I know UEFI doesn't have threads but there are places in code that use things like EFI_MP_SERVICES, can the APs never touch certain code (like filesystem code, for example)?

Best Regards,

Pedro