Hi Michael,<br /><br />Sorry for the delay, I've been quite busy with work these past few days.<br /><br />Yes, it sounds good, I'll keep it on a separate repo until it's actually more or less mature.<br /><br />As for your questions,<br /><br />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.<br />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<br />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.<br /><br />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,<br />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,<br />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<br />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.<br />It might be that the chance of this happening is minimal, but that doesn't sit right with me.<br /><br />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<br />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)?<br /><br />Best Regards,<br /><br />Pedro