On Wed, 17 Aug 2022 at 11:22, Laszlo Ersek <[email protected]> wrote: > > On 08/17/22 10:39, Ard Biesheuvel wrote: > > > Agree with all of the above. At this point, I think the only way to do > > this properly is to create an alternative UefiDriverEntrypoint library > > with the fw_cfg check folded into it. This is easy to do and addresses > > all the concerns raised here (as it can force the driver entry point > > function to return any value at any point) but the code duplication is > > unfortunate. > > Ah, that's very creative. I didn't think of duplicating and customizing > the entry point library! >
Yeah, I'll spin a v2 based on this idea. > > On Tue, 16 Aug 2022 at 23:10, Brian J. Johnson <[email protected]> > > wrote: > >> I don't know how any physical machine handles that particular option. > >> But one approach would be to add a GUID to the depex of the module > >> you want to control, and install it only when you want the module to > >> be dispatched. That's pretty straightforward, although it does > >> result in "Driver %g was discovered but not loaded!!" messages from > >> CoreDisplayDiscoveredNotDispatched() if sufficient debugging is > >> enabled. > >> > > > > I think the diagnostic is fine. But I don't think adding DEPEXes to > > UEFI drivers (as opposed to DXE drivers) is proper, or even supported. > > It would also require the drivers in other packages to be updated. > > Sigh, I'm totally getting rusty on all this (which is quite expected). > You are right about the difference between DXE and UEFI drivers wrt. > depexes. :/ > > > What i i like about the current approach is that the library can tie > > any driver or app dispatch to any fw_cfg variable in QEMU (provided > > that its build is directed by the .dsc in question). Switching to an > > alternate UefiDriverEntrypoint implementation would limit this to > > drivers, but this is fine for the purpose at hand. > > Just don't forget that the number of fw_cfg slots in QEMU is limited. It > is exposed as an experimental property (x-file-slots) of the fw_cfg_io > and fw_cfg_mem on-board devices. It matters for migration, and so it is > versioned. It used to be 0x10, for the 2.8 and earlier machine types, > and has been 0x20 for later machine types. See QEMU commit a5b3ebfd23bc. > > IOW, while the mechanism in edk2 could scale "indefinitely", QEMU will > in effect limit the number of fw_cfg files that can be used for this > purpose too. > Right, that is good to know. But I don't think the point here is to make each individual driver controllable from the command line. The goal here is really to make this work in a way that is generic (i.e., not specific to networking) that doesn't require changes to the other packages. -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#92520): https://edk2.groups.io/g/devel/message/92520 Mute This Topic: https://groups.io/mt/93032846/21656 Group Owner: [email protected] Unsubscribe: https://edk2.groups.io/g/devel/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
