From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from blyat.fensystems.co.uk (blyat.fensystems.co.uk [54.246.183.96]) by mx.groups.io with SMTP id smtpd.web08.56836.1622548605585107040 for ; Tue, 01 Jun 2021 04:56:46 -0700 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: ipxe.org, ip: 54.246.183.96, mailfrom: mcb30@ipxe.org) Received: from pudding.home (unknown [213.205.240.7]) by blyat.fensystems.co.uk (Postfix) with ESMTPSA id A27404424B; Tue, 1 Jun 2021 11:56:41 +0000 (UTC) Subject: Re: [edk2-devel] GSOC 2021 EXT4 driver Project To: Pedro Falcato , devel@edk2.groups.io References: <1bac9489-2613-3fd4-15ba-a2ba8d69f54e@ipxe.org> <26236.1622222181130619436@groups.io> From: "Michael Brown" Message-ID: <5ade005a-a045-4b2f-0f15-f2e5c3fdc871@ipxe.org> Date: Tue, 1 Jun 2021 12:56:41 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0 MIME-Version: 1.0 In-Reply-To: <26236.1622222181130619436@groups.io> X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on blyat.fensystems.co.uk Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit 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