1) The demand is a bit suppressed due to good-old bios boot. Evolving non-tftp transfer happened in x86 BIOS land driven by need not addressed in standards bodies, and thus far that audience has mostly ignored UEFI out of practical concerns and no urgent need to ditch BIOS. I'm content with keeping it in my tree, just thought I'd share if someone else had interest. We are starting to see real problems where UEFI boot on x86 becomes imperative as opposed to not providing much practical benefit, so I needed something today.
2) GRUB2 may be the correct long term place, but at the moment I don't see any UEFI netboot support there (maybe I don't know where to look?) and I'm not particularly excited about starting from scratch given my time limitations. Historically, Grub hasn't done much to be a good network boot loader and in legacy world, pxelinux has persisted to compensate for that gap. For me, elilo is serving the analogous role as it's design is significantly easier for me to follow and modify. Hopefully things are better in grub world, last time I saw the topic broached (admittedly year (s) ago), there seemed to be a fairly 'anti-firmware' sentiment on netboot, saying the only right way was to compile in whatever drivers you want. Judging from the non-UEFI PXE code, it looks like that has changed in BIOS land, but UEFI land hasn't seen any implementation.... From: Jason Fleischli <[email protected]> To: Jarrod B Johnson/Raleigh/IBM@IBMUS Date: 09/07/2011 12:38 PM Subject: Re: [elilo-discuss] elilo patch for iPXE download protocol Hey Jarrod, Following up with you on this since the ball was left in my court last. came in at a really busy time as elilo is a spare time deal... anyway, I wanted to ask a couple of things. 1.) Sell me ;), why should we care to add this into elilo which is pretty much in legacy support mode from my perspective especially once the "GRand Unified Bootloader" is fully up to speed on EFI/UEFI support. I havent had any inquiries or requests for iPxe support. Whats the community benefit at this stage? 2.) along those lines, why not put it into grub? even UEFI systems are bootable via (nonefi)grub which has supported chain loading for a long time unlike elilo. cheers, -jason On Wed, 2011-08-17 at 07:14 -0600, Jarrod B Johnson wrote: > Ok, I've attached a revised patch where the function looks sane and > has some chance at working in more build envs. Michael Brown from iPXE > suggested something like: > #ifdef __GNUC__ > #if __x86_64__ > #define EFIAPI __attribute__((ms_abi)) > #elif __i386__ > #define EFIAPI __attribute__((cdecl,regparm(0))) > #endif > #endif > > Which I put into netfs.h. I would think gnu-efi would want to change > to this and then get to change uefi_call_wrapper to be a whole lot > more straightforward for existing code and not necessary at all for > new code. In theory, that would mean that probably a lot of elilo > functions might consider changing to add that prefix, though it > doesn't really matter except for functions called from outside of > elilo itself (which could get complicated for the likes of efi_main, > considering crt0 current assumptions). > > (See attached file: elilo-ipxe.patch) > > Inactive hide details for Jarrod B Johnson---08/16/2011 06:50:25 > PM---Being lazy, I took the distro provided one, gnu-efi-3.0g>Jarrod B > Johnson---08/16/2011 06:50:25 PM---Being lazy, I took the distro > provided one, "gnu-efi-3.0g-2.el6.x86_64". I also submitted to iPXE l >
<<inline: graycol.gif>>
------------------------------------------------------------------------------ Using storage to extend the benefits of virtualization and iSCSI Virtualization increases hardware utilization and delivers a new level of agility. Learn what those decisions are and how to modernize your storage and backup environments for virtualization. http://www.accelacomm.com/jaw/sfnl/114/51434361/
_______________________________________________ elilo-discuss mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/elilo-discuss
