> 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
