From mboxrd@z Thu Jan 1 00:00:00 1970 Subject: Re: [edk2-devel] GSOC 2021 EXT4 driver Project To: Michael Brown ,devel@edk2.groups.io From: "Pedro Falcato" X-Originating-Location: Seixal, District of Setúbal, PT (85.241.253.151) X-Originating-Platform: Linux Chrome 90 User-Agent: GROUPS.IO Web Poster MIME-Version: 1.0 Date: Fri, 28 May 2021 10:16:21 -0700 References: <1bac9489-2613-3fd4-15ba-a2ba8d69f54e@ipxe.org> In-Reply-To: <1bac9489-2613-3fd4-15ba-a2ba8d69f54e@ipxe.org> Message-ID: <26236.1622222181130619436@groups.io> Content-Type: multipart/alternative; boundary="hID4x9PHLWGJB7bDpedb" --hID4x9PHLWGJB7bDpedb Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable 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 m= ore or less mature. As for your questions, 1) I'm planning to make this read-write, but most importantly, I want it t= o be solid. If I can't reach write support, it's okay, since it's just a st= retch goal. My idea was to get solid read-only support, as it's naturally the most imp= ortant part of a firmware filesystem driver (and as far as I know, there ar= e not many EFI applications/bootloaders that write to the filesystem). If I get the d= esired 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 fa= miliar 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 p= artitions 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 l= ook 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 prim= itives (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 --hID4x9PHLWGJB7bDpedb Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable 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 sepa= rate repo until it's actually more or less mature.

As for your q= uestions,

1) I'm planning to make this read-write, but most impo= rtantly, 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 sup= port, as it's naturally the most important part of a firmware filesystem dr= iver (and as far as I know, there are not many
EFI applications/bootlo= aders 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 ess= entially unable to boot to those partitions until
someone gets a recov= ery drive of some sort that has a 'fsck' on it? I hope the FAT32 code has s= ome answers for me, but I haven't had the time to go look at it that closel= y 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 fir= mware code need the usual synchronization primitives (only spinlocks in thi= s case, I would assume) or is it just assumed that it's a single threadedenvironment? I know UEFI doesn't have threads but there are places in c= ode that use things like EFI_MP_SERVICES, can the APs never touch certain c= ode (like filesystem code, for example)?

Best Regards,

Pedro --hID4x9PHLWGJB7bDpedb--