Hi everyone, now don't get me wrong, I understand why the shell was written the way it is now and that this is probably the cleanest solution. Things change during development and not always is backward compatibility the best option or even possible. The point I was trying to make is:
- not every UEFI developer follows every change that happens in the dev version or the edk2 mailing list - therefore, if backward-compatibility gets broken, it should be stated in a clear and unmistakeable way in the release notes (and not just in a side mention): X got removed, therefore Y will break and you have to change Z to make it work again - If certain features only work in or above certain UEFI revisions, this should be stated the same way - instead of immediately removing things and breaking backward compatibility, it would be better to mark them as "deprecated", keep them so they are still usable and remove them in the next version so developers have time to adapt their programs instead of being left with non-working things from one day to another. In this case e.g.: Keep the backward compatibility in UDK2015, but mention clearly in the release notes that EFI_IP4_CONFIG_PROTOCOL got deprecated and will be removed in the next version The ideal solution, but probably also the most complicated and the one involving most work, would be a build-option approach like Samer suggested. E.g., you can only use deprecated things with the build option "-unsafe", otherwise the compiler will throw an error about using deprecated things. One could extend this to UEFI revisions - e.g. if you provide the build option "-uefi240", the compiler will throw an error if something is used that is only available in an UEFI revision > 2.40 - or isn't available in 2.40 anymore. Now to something completely unrelated, for which I hope to get an answer nevertheless (if I shall "open" a new e-mail "thread", please tell me). One of the applications I wanted to include in the shell is made using EADK, specifically the socket library. I got it integrated and can run it from the shell, however all EADK related things don't seem to work - e.g. if I use printf(), nothing happens, the UEFI Print() however works. Is this a mistake on my side or does EADK generally not work when used from applications integrated into the shell? I saw the know issue in the readme.txt from AppPkg (2. Applications must be launched from within the EFI Shell.), but thought running it from the shell or integrating it into the shell would make no technical difference. Greetings Johannes -----Original Message----- From: af...@apple.com [mailto:af...@apple.com] Sent: Thursday, November 12, 2015 5:11 AM To: El-Haj-Mahmoud, Samer Cc: Conen, Johannes; ler...@redhat.com; jiaxin...@intel.com; edk2-de...@ml01.01.org; jaben.car...@intel.com; ting...@intel.com; leif.lindh...@linaro.org Subject: Re: [edk2] ShellPkg: Network commands (ifconfig/ping) broken > On Nov 11, 2015, at 8:03 PM, El-Haj-Mahmoud, Samer > <samer.el-haj-mahm...@hpe.com> wrote: > > I remember we specifically discussed this in the UEFI Forum and decided to > drop the If4ConfigProtocol compatability from the spec. > > If edk2 would like to keep it, it can be done, but will complicate things. I > would recommend a build option to disable /remove the legacy support as new > platforms don't care about this in their shell (if the shell is embedded or > targets specific platforms). > Samer, I don't think this is a spec conformance issue. It is easy for a ROM to pick a given version of UEFI to conform to. The problem is an application as Johannes has pointed out can run on different ROMs that implement different versions of UEFI. >From an implementation standpoint it should be possible for the Application to >check the UEFI revision and "do the correct thing". So I think the objection >is the shell was written to strictly conform to the latest UEFI specification, >when it could have been made backward compatible with a range of UEFI >specification versions. Thanks, Andrew Fish > > Thanks > Samer > > > > Sent from my Android phone using Symantec TouchDown (www.symantec.com) > > -----Original Message----- > From: Ye, Ting [ting...@intel.com] > Received: Wednesday, 11 Nov 2015, 7:41PM > To: Conen, Johannes [johannes.co...@siemens.com]; Laszlo Ersek > [ler...@redhat.com]; Wu, Jiaxin [jiaxin...@intel.com]; > edk2-devel@lists.01.org [edk2-de...@ml01.01.org]; Carsey, Jaben > [jaben.car...@intel.com] > CC: Leif Lindholm (Linaro address) [leif.lindh...@linaro.org] > Subject: Re: [edk2] ShellPkg: Network commands (ifconfig/ping) broken > > One solution to support UEFI 2.4 network modules with UEFI 2.5 ifconfig is to > add the code back to use HII services to perform setting. The definition of > NIC_IP4_CONFIG_INFO and a private GUID gEfiNicIp4ConfigVariableGuid should be > added into ShellPkg as UEFI 2.5 no longer keep the definition in > MdeModulePkg. This will bring complexity to ShellPkg. > > Also, more older network modules even uses a private protocol NicIp4Config > protocol (defined in EdkCompatibilityPkg) to fix the issue in > EFI_IP4_CONFIG_PROTOCOL. When Shell commands upgrade to Shell 2.0, the > ifconfig removes the support of this protocol. Does the UEFI 2.5 ifconfig > need support this protocol also to co-work with older platform? > > Jaben, what's your opinion about this? > > Best Regards, > Ye Ting > > > -----Original Message----- > From: Conen, Johannes [mailto:johannes.co...@siemens.com] > Sent: Wednesday, November 11, 2015 8:22 PM > To: Ye, Ting; Laszlo Ersek; Wu, Jiaxin; edk2-devel@lists.01.org > Cc: Leif Lindholm (Linaro address) > Subject: AW: [edk2] ShellPkg: Network commands (ifconfig/ping) broken > > Hi everyone, > > I started with UEFI development only recently, in September, with UDK2014. > When UDK2015 was released and there was no explicit notice of it being > incompatible with UDK2014 platforms, I expected to be able to switch to it > without any problems - I didn't expect forward compatibility, but backward > compatibility like in most other development environments (e.g. if I write an > application with the C95 standard, my application will still work with C99, > but not the other way round). If I understood you correctly, neither the one > nor the another is given atm - the UDK2014 shell won't work with UEFI 2.50 > platforms as the EFI_IP4_CONFIG_PROTOCOL is not present and the UDK2015 shell > won't work with UEFI 2.40 platforms as the EFI_IP4_CONFIG2_PROTOCOL is not > present. > > I don't think you can expect every UEFI developer to be on the EDK2 mailing > list - I wasn't until a few days ago, the discussions about deprecating the > protocol were in April and July according to the mail attachments from Jiaxin > and with the amount of e-mails being sent over this mailing list on a daily > basis, I doubt everyone will take notice of everything. For me as someone who > is not involved into the development of EDKII itself, 90% of those e-mails > are completely irrelevant to me and get deleted immediately. > > Now, I don't write UEFI firmwares, but UEFI applications - for testing our > computers before they leave the production factory. Something being > incompatible with previous versions (getting deprecated doesn't necessarily > mean it doesn't work anymore, only it shouldn't be used anymore) is a pretty > important notice to me as I need to rewrite all applications that are > affected by this as soon as our firmware developers switch to > UDK2015/UEFI2.50 - or maintain two versions of my applications while some > computers are still being shipped with UEFI 2.40 and others with UEFI 2.50. > AFAIK (please correct me if I'm wrong there), until now, every application > developed with an earlier version of EDK/EDKII could be used on platforms > developed with later versions, too - e.g. I was able to use the applications > shipped with the original EDK (like the ramdisk driver or the ftp client) on > my UEFI 2.40 platform. That changing is a pretty big deal and should clearly > be communicated within the release notes. > > In this specific case, I wanted to customize the shell to include our > diagnostic programs so we can boot the shell over PXE, run our diagnostics > and send the results back to a server (therefore the need for ifconfig), thus > eliminating the need for an EFI USB stick. Now, depending on which UEFI > platform the PC has, we need to boot either the UEFI 2.40 compatible shell or > the UEFI 2.50 compatible shell - which makes things a bit more complicated. > > Greetings > Johannes > > > -----Ursprüngliche Nachricht----- > Von: Ye, Ting [mailto:ting...@intel.com] > Gesendet: Mittwoch, 11. November 2015 04:36 > An: Conen, Johannes; Laszlo Ersek; Wu, Jiaxin; edk2-devel@lists.01.org > Cc: Leif Lindholm (Linaro address) > Betreff: RE: [edk2] ShellPkg: Network commands (ifconfig/ping) broken > > Hi Johannes, > > I would like to add some background info here: > > The original EFI_IP4_CONIFG_PROTOCOL has design issue that it cannot function > well for a driver or an application (e.g. ifconfig) to configure static > address. To solve this issue, ifconfig in UDK2014 defines a structure > NIC_IP4_CONFIG_INFO and a private GUID gEfiNicIp4ConfigVariableGuid in > NicIp4ConfigNvData.h under MdeModulePkg in order to deploy configuration > through HII service. This is absolutely not a clean design. > > In order to solve this issue, and also introduce new capabilities like > configure DNS server address to IP4Config; a new protocol > EFI_IP4_CONFIG2_PROTOCOL is introduced to UEFI 2.5 specification. The UEFI > forum also discussed whether need keep EFI_IP4_CONFIG_PROTOCOL for backwards > compatibility in a long period. Since the forum doesn't receive any objection > during the period, and the team members prefer a clean design, the UEFI spec > deprecates the EFI_IP4_CONFIG_PROTOCOL finally. > > When Intel working on UDK2015 implementation, we also reported to EDKII > mailing list that we would like to deprecate the support of > EFI_IP4_CONFIG_PROTOCOL (see Jiaxin's mail). Also we don't receive any > objections and comments on this. To make a clean implementation, the UDK2015 > removes Ip4ConfigDxe driver and adds the support of EFI_IP4_CONFIG2_PROTOCOL > to Ip4Dxe driver. Also, to make ifconfig under ShellPkg clean, the > application only supports EFI_IP4_CONFIG2_PROTOCOL. > > Thus, current supported usage is to use UDK2014 shell commands with UDK 2014 > network modules and use UDK2015 shell command with UDK2015 network modules. > > Now I would like to understand your usage. -- Do you intend to use new shell > commands with UDK2014 network modules? > > > Best Regards, > Ye Ting > > > -----Original Message----- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > Conen, Johannes > Sent: Tuesday, November 10, 2015 6:21 PM > To: Laszlo Ersek; Wu, Jiaxin; edk2-devel@lists.01.org > Cc: Leif Lindholm (Linaro address) > Subject: Re: [edk2] ShellPkg: Network commands (ifconfig/ping) broken > > Hmm, you're right..... is it briefly mentioned in the "ShellPkg Notes.txt" - > I must admit, I only took a look at the > "UDK2015-ReleaseNotes-MyWorkSpace.txt" and expected all major changes to > mentioned there (and well, they were, like the moving of the library files). > So this non-backwards-compatibility from UDK2015 to UDK2014 regarding > network-related stuff is intended? > > Greetings > Johannes > > -----Ursprüngliche Nachricht----- > Von: Laszlo Ersek [mailto:ler...@redhat.com] > Gesendet: Dienstag, 10. November 2015 11:06 > An: Conen, Johannes; Wu, Jiaxin; edk2-devel@lists.01.org > Cc: Leif Lindholm (Linaro address) > Betreff: Re: [edk2] ShellPkg: Network commands (ifconfig/ping) broken > > On 11/10/15 10:49, Conen, Johannes wrote: >> Hi there, >> >> I made my tests with the binary shell from ShellBinPkg from UDK2014, >> from UDK2015, the current master and a few commits in between and >> rebuilt the shell from ShellPkg for UDK2014, UDK2015, the current >> master and a few commits in between UDK2014 and UDK2015. >> >> It worked fine with r17868 and didn't work anymore with r17869, so it >> has to be that commit (I of course rebuilt the shell from ShellPkg). >> If I put both shells on a USB-stick and switch between them on the >> fly, it works in the one built from r17868 and doesn't work in the >> one built from r17869. Regarding ShellBinPkg: the last version that >> worked is r17619 (which is quite logical since the version after >> that, r18187, is built from ShellPkg r18186, which didn't work for me >> anymore). >> >> I'm not working on OVMF, but on real hardware (X64) - don't know >> exactly with which version the UEFI firmware was written, but I >> assume it's UDK2014. I found nothing in the release notes that would >> break backwards compatibility to firmware versions built with older >> EDKII versions in this regard. > > Okay, that seems to explain it. The platform firmware on your physical > machine provides Ip4Config (version 1) only, but the shell built from recent > edk2 (and probably the binary shipped in UDK2015) requires Ip4Config2. > > Hm... I have not been a UDK user, but now I downloaded "UDK2015.Notes.zip", > and in "ShellPkg Notes.txt", it says under "NEW FEATURES AND CHANGES", point > 15: > > Change "ping" and "ifconfig" code to consume Ip4Config2 protocol. > > So I think this has been (technically) documented in the UDK2015 release. > Perhaps the lack of compatibility with UDK2014 should have been emphasized. > > (But, I'm just a curious bystander in this discussion anwyay...) > > Thanks > Laszlo > >> >> With best regards, >> Johannes Conen >> >> Siemens AG >> Process Industries and Drives Division Process Automation >> Manufacturing Karlsruhe PD PA MF-K IPC 2 Oestliche Rheinbrueckenstr. >> 50 >> 76187 Karlsruhe, Germany >> mailto:johannes.co...@siemens.com >> >> >> -----Ursprüngliche Nachricht----- >> Von: Wu, Jiaxin [mailto:jiaxin...@intel.com] >> Gesendet: Dienstag, 10. November 2015 02:42 >> An: Laszlo Ersek; Conen, Johannes; edk2-devel@lists.01.org >> Cc: Leif Lindholm (Linaro address) >> Betreff: RE: [edk2] ShellPkg: Network commands (ifconfig/ping) broken >> >> Hi Laszlo and Conen, >> Thanks for your reply, I have double checked the ShellBinPkg and ShellPkg in >> UDK2015 release version, Both of them have included my patch for Ip4Config >> Protocol deprecated work. >> I'm also confused by the test result below, seems only time appeared >> abnormal. >> >> Conen: Are you using the shell binary released in UDK2015? >> >> Thanks. >> Jiaxin >> >> -----Original Message----- >> From: Laszlo Ersek [mailto:ler...@redhat.com] >> Sent: Tuesday, November 10, 2015 4:30 AM >> To: Conen, Johannes; edk2-devel@lists.01.org >> Cc: Leif Lindholm (Linaro address); Wu, Jiaxin >> Subject: Re: [edk2] ShellPkg: Network commands (ifconfig/ping) broken >> >> On 11/09/15 16:52, Conen, Johannes wrote: >>> Hello everyone, >>> >>> after switching from UDK2014 to UDK2015, I noticed that the network >>> commands (ifconfig / ping) don't work anymore. ifconfig just exits >>> with no feedback and ping says "Config no mapping" (logical, as it >>> is not possible to get an IP address via ifconfig). In UDK2014 >>> everything worked fine. >>> >>> With the help of unixsmurf (thanks a lot) >> >> Argh. Can we stop using these "funny" nicks on IRC? >> >> "unixsmurf" is Leif. >> >> What do you think, Leif? :) >> >>> I went on bughunting and >>> found out that commit r17869 / git sha >>> 7c25b7ea5b2c029a9e7a0be57f7c20f31d720c7d broke it. Wild guess: it >>> has something to do with the new protocol. >> >> That's close, but my take is not that exact commit. Instead, what >> about >> this: >> >> https://github.com/tianocore/edk2/commit/2aa0eb5df61e >> >> == SVN rev 17917. >> >> (I reviewed that commit.) >> >> But, it works for me: >> >>> Shell> ifconfig -s eth0 dhcp >>> Shell> ifconfig -l eth0 >>> >>> ----------------------------------------------------------------- >>> >>> name : eth0 >>> Media State : Media present >>> policy : dhcp >>> mac addr : 52:54:00:29:80:AE >>> >>> ipv4 address : 192.168.122.182 >>> >>> subnet mask : 255.255.255.0 >>> >>> default gateway: 192.168.122.1 >>> >>> Routes (2 entries): >>> Entry[0] >>> Subnet : 192.168.122.0 >>> Netmask: 255.255.255.0 >>> Gateway: 0.0.0.0 >>> Entry[1] >>> Subnet : 0.0.0.0 >>> Netmask: 0.0.0.0 >>> Gateway: 192.168.122.1 >>> >>> DNS server : >>> 192.168.122.1 >>> >>> >>> ----------------------------------------------------------------- >>> Shell> ping 8.8.8.8 >>> Ping 8.8.8.8 16 data bytes. >>> 16 bytes from 8.8.8.8 : icmp_seq=1 ttl=0 time=30640ms >>> 16 bytes from 8.8.8.8 : icmp_seq=2 ttl=0 time=31249ms >>> 16 bytes from 8.8.8.8 : icmp_seq=3 ttl=0 time=33280ms >>> 16 bytes from 8.8.8.8 : icmp_seq=4 ttl=0 time=38577ms >>> 16 bytes from 8.8.8.8 : icmp_seq=5 ttl=0 time=28432ms >>> 16 bytes from 8.8.8.8 : icmp_seq=6 ttl=0 time=31275ms >>> 16 bytes from 8.8.8.8 : icmp_seq=7 ttl=0 time=26576ms >>> 16 bytes from 8.8.8.8 : icmp_seq=8 ttl=0 time=33192ms >>> 16 bytes from 8.8.8.8 : icmp_seq=9 ttl=0 time=31112ms >>> 16 bytes from 8.8.8.8 : icmp_seq=10 ttl=0 time=28237ms >>> >>> 10 packets transmitted, 10 received, 0% packet loss, time 312570ms >>> >>> Rtt(round trip time) min=26576ms max=38577ms avg=31257ms >> >> This on OVMF just built from edk2 at SVN rev18759. (Note that in OVMF >> the shell is built from source as well.) >> >>> Personally I think this is a critical issue - it practically makes >>> it impossible to use any network related stuff in the UEFI shell. >> >> I suspect that you are using an old (UDK2014) shell binary on top of a new >> (UDK2015) network stack, or vice-versa. >> >> If you check the commit message of SVN rev 17917 / git 2aa0eb5df61e, >> it said that it was safe to remove the Ip4Config protocol *because* >> SVN rev >> 17869 / git 7c25b7e [that you have found] had already moved ping / ifconfig >> to the new protocol. >> >> And at the time of SVN rev 17869 / git 7c25b7e, the new protocol existed >> (see SVN rev 17853 / git 1f6729ffe980). >> >> In chronological order: >> - SVN rev 17853 / git 1f6729ff: implements the Ip4Config2 protocol, >> - SVN rev 17869 / git 7c25b7ea: migrates ping & ifconfig to >> Ip4Config2, >> - SVN rev 17917 / git 2aa0eb5d: removes Ip4Config (no more users) >> >> So, assuming you build *all* of your firmware from edk2, from source, >> including the shell, you should end up with working ping & ifconfig at any >> stage. >> >> I don't know at what stage UDK2015 was packaged. If it happened after >> SVN rev 17917 / git 2aa0eb5d, then I guess the message of that commit >> applies: "Ip4ConfigDxe driver is deprecated in UEFI 2.5, so we will not >> support original Ip4Config Protocol" -- please use a conformant shell I >> guess. >> >> I'm still a bit confused, because ShellBinPkg was also updated in SVN rev >> 18187 / git 1fe76acc, which was about a month after SVN rev 17917 / git >> 2aa0eb5d above. So unless Intel released UDK2015 exactly within that one >> month, I cannot see how you can encounter this problem. >> >> Are you using a shell binary whose source is still based on UDK2014 (or >> older)? >> >> Thanks, >> Laszlo >> >> >>> With best regards, >>> Johannes Conen >>> >>> Siemens AG >>> Process Industries and Drives Division Process Automation >>> Manufacturing Karlsruhe PD PA MF-K IPC 2 Oestliche Rheinbrueckenstr. >>> 50 >>> 76187 Karlsruhe, Germany >>> mailto:johannes.co...@siemens.com >>> >>> >>> _______________________________________________ >>> edk2-devel mailing list >>> edk2-devel@lists.01.org >>> https://lists.01.org/mailman/listinfo/edk2-devel >>> >> > > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
