[edk2-devel] GSOC 2021 EXT4 driver Project
Michael Brown
mcb30 at ipxe.org
Tue Jun 1 11:56:41 UTC 2021
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
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#75895): https://edk2.groups.io/g/devel/message/75895
Mute This Topic: https://groups.io/mt/83060185/1813853
Group Owner: devel+owner at edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [edk2-devel-archive at redhat.com]
-=-=-=-=-=-=-=-=-=-=-=-
More information about the edk2-devel-archive
mailing list