Re: [edk2-devel] GSOC 2021 EXT4 driver Project

["Michael Brown" <mcb30@ipxe.org>]

On 28/05/2021 18:16, Pedro Falcato wrote:
> 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.

I don't know the internals of Ext4 journalling well enough to comment in 
detail, but my guess is that you are likely to find that some aspects 
are required for correctness but some aspects are required only for fast 
write performance with multiple concurrent processes (which is 
completely irrelevant for boot firmware).

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

UEFI is fundamentally single-process, single-threaded, and based on 
polling rather than interrupts.  It is _almost_ a clean design in which 
code never needs to worry about locking or other forms of synchronization.

Unfortunately this design is compromised by the existence of UEFI 
timers.  There is no way to hook in a useful hardware interrupt (e.g. 
for a NIC received packet), but there are timer interrupts that will 
fire at unpredictable times and can result in arbitrary callbacks being 
invoked.

This introduces a requirement for some kind of synchronization, which 
UEFI handles via RaiseTPL()/RestoreTPL().  You can use RaiseTPL() to 
effectively disable timer interrupts and thereby guarantee that your 
code will not be reentered.

There is essentially no formal specification of what code should be 
allowed to run at each TPL, so your only viable option is to dig through 
existing EDK2 implementations to infer the de facto requirements.

Michael