From: "Marvin Häuser" <mhaeuser@posteo.de>
To: Ada Christine <adachristine18@gmail.com>
Cc: discuss@edk2.groups.io, nathaniel.l.desimone@intel.com,
steven.shi@intel.com, devel@edk2.groups.io
Subject: Re: [edk2-discuss] GSoC Proposal
Date: Wed, 13 Apr 2022 12:05:31 +0000 [thread overview]
Message-ID: <02629740-16E4-49EA-B627-B0FEF0E4E3D3@posteo.de> (raw)
In-Reply-To: <14039.1649847289490383262@groups.io>
Do you use the “reply all” option in your mail client? Looks like my CCs have been dropped again. Comments inline.
> On 13. Apr 2022, at 12:54, Ada Christine <adachristine18@gmail.com> wrote:
> Hi, Marvin
>
> Its similarity to my own latest experiment is the key to what grabbed my attention. I have no particular use case in mind for it, but I see its potential for anybody developing larger applications in that when a library is changed there's no need to distribute a new version of the whole binary, just the relevant library module.
I really do not like the trend of treating UEFI as a full-fledged OS - it is not. The most used UEFI applications, OS loaders, are really not that huge and are distributed as part of the OS image anyway. Even for less used applications, you will always get a full snapshot anyhow. Gladly we don’t have auto-update and package management yet. :)
>
> I slept on it and it occurred to me that the whole thing could operate similarly to the shell protocol in that the linker/loader is itself an application that does a LoadImage() on the application needing dynamic linking facilities.
That would mean the linker itself is shipped with every application that requires it? Otherwise it doesn’t make much sense for it to be an app and below’s problems apply.
> If however the whole plan is making the linker as a DXE and including it with the firmware, that I'm not quite as sure about. That would necessarily tie any applications using dynamic linking to TianoCore or any firmware distribution that derives from it.
I think that was the idea referred to as “edk2 core” by Steven, but I’d like to hear his proposal to be sure. Virtually everyone uses edk2, so that itself is not the problem, but versioning is. Vendors are slow to update their snapshots or have just given up doing that entirely. Distributing it for external applications like OS loaders would mean this can be leveraged probably no earlier than 10 years from now. And for in-firmware things, I have a hard time thinking about a use-case that outweighs the drawbacks.
>
> To shift the topic slightly back to GSoC, however, I'm willing to work on other items on the task list. Unit testing and an ACPICA application are the alternative projects I had thought about. I need to choose fairly soon as the proposal deadline is next Tuesday. I know a tiny bit about porting ACPICA as I also have plans to incorporate it into my own project.
I have a few more ideas for security stuff, but Nate did not confirm them as appropriate yet and I’m not here to drive you away from this specific task (or the others). However, I’m still curious and concerned. :)
Best regards,
Marvin
next parent reply other threads:[~2022-04-13 12:05 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <14039.1649847289490383262@groups.io>
2022-04-13 12:05 ` Marvin Häuser [this message]
2022-04-13 14:38 ` [edk2-discuss] GSoC Proposal Ada Christine
2022-04-13 15:15 ` Marvin Häuser
2022-04-13 17:53 ` Ada Christine
2022-04-13 18:46 ` [edk2-devel] " Pedro Falcato
2022-04-13 18:42 ` Pedro Falcato
2022-04-13 19:14 ` Marvin Häuser
2022-04-13 22:57 ` Nate DeSimone
2022-04-14 1:30 ` Ada Christine
2022-04-14 7:55 ` Marvin Häuser
2022-04-15 1:06 ` Nate DeSimone
2022-04-15 2:42 ` Andrew Fish
2022-04-15 6:56 ` Marvin Häuser
2022-04-15 8:15 ` Nate DeSimone
2022-04-15 12:09 ` Ada Christine
2022-04-15 12:31 ` Marvin Häuser
2022-04-15 13:31 ` Zimmer, Vincent
2022-04-15 13:39 ` Marvin Häuser
2022-04-15 14:53 ` Zimmer, Vincent
2022-04-15 15:02 ` Yao, Jiewen
2022-04-15 16:00 ` Marvin Häuser
2022-04-15 16:22 ` Brian J. Johnson
2022-04-15 16:44 ` Marvin Häuser
2022-04-15 18:47 ` Oram, Isaac W
2022-04-15 19:04 ` Marvin Häuser
2022-04-16 4:23 ` Nate DeSimone
2022-04-16 13:36 ` Ada Christine
2022-04-18 17:54 ` Brian J. Johnson
2022-04-13 22:56 ` Nate DeSimone
[not found] <t4R6.1649786926384402958.oz5x@groups.io>
2022-04-13 6:54 ` Marvin Häuser
2022-04-13 14:44 ` Rebecca Cran
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=02629740-16E4-49EA-B627-B0FEF0E4E3D3@posteo.de \
--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