From: "Pedro Falcato" <pedro.falcato@gmail.com>
To: Michael Brown <mcb30@ipxe.org>,devel@edk2.groups.io
Subject: Re: [edk2-devel] GSOC 2021 EXT4 driver Project
Date: Fri, 28 May 2021 10:16:21 -0700 [thread overview]
Message-ID: <26236.1622222181130619436@groups.io> (raw)
In-Reply-To: <1bac9489-2613-3fd4-15ba-a2ba8d69f54e@ipxe.org>
[-- Attachment #1: Type: text/plain, Size: 1867 bytes --]
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 more or less mature.
As for your questions,
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.
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
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.
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.
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)?
Best Regards,
Pedro
[-- Attachment #2: Type: text/html, Size: 1959 bytes --]
next prev parent reply other threads:[~2021-05-28 17:16 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-24 19:26 GSOC 2021 EXT4 driver Project Pedro Falcato
2021-05-24 20:26 ` [edk2-devel] " Michael D Kinney
2021-05-24 23:15 ` Michael Brown
2021-05-28 17:16 ` Pedro Falcato [this message]
2021-06-01 11:56 ` Michael Brown
2021-06-10 17:38 ` Michael D Kinney
2021-06-10 17:54 ` Leif Lindholm
2021-06-11 18:23 ` Michael Kubacki
2021-06-11 21:27 ` Michael D Kinney
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=26236.1622222181130619436@groups.io \
--to=devel@edk2.groups.io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox