From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: solarflare.com, ip: 67.231.154.164, mailfrom: tpilar@solarflare.com) Received: from dispatch1-us1.ppe-hosted.com (dispatch1-us1.ppe-hosted.com [67.231.154.164]) by groups.io with SMTP; Thu, 23 May 2019 02:46:38 -0700 X-Virus-Scanned: Proofpoint Essentials engine Received: from webmail.solarflare.com (webmail.solarflare.com [12.187.104.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mx1-us4.ppe-hosted.com (PPE Hosted ESMTP Server) with ESMTPS id C360CB4005B; Thu, 23 May 2019 09:46:36 +0000 (UTC) Received: from tp-desktop.uk.solarflarecom.com (10.17.20.51) by ocex03.SolarFlarecom.com (10.20.40.36) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 23 May 2019 02:46:32 -0700 Subject: Re: [edk2-devel] iSCSI and iBFT To: , , Laszlo Ersek References: <3644c44636fb4fe5b719128ec1443b4c@ukex01.SolarFlarecom.com> <1c6545291d0f460fac20abf2187a551c@ukex01.SolarFlarecom.com> <29d7e6a4-667a-7929-f4e3-96303ed0d39d@solarflare.com> <006adde9-25fd-bdd8-1bda-bbea4302e777@ipxe.org> From: "Tomas Pilar (tpilar)" Message-ID: Date: Thu, 23 May 2019 10:46:30 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.0 MIME-Version: 1.0 In-Reply-To: <006adde9-25fd-bdd8-1bda-bbea4302e777@ipxe.org> X-Originating-IP: [10.17.20.51] X-TM-AS-Product-Ver: SMEX-12.5.0.1300-8.5.1010-24632.005 X-TM-AS-Result: No-6.975800-4.000000-10 X-TMASE-MatchedRID: UuaOI1zLN1g4dpJ/daE63Iph1hAtvKZNUa2X25F2wo8FosTuOMoNEIQI hql4dbvdNe7yncYhXDxN7vNyfwmp4VCzCCPQc6/cRUf605p9JUPr1pL7v/NuP55P2QBLGjgx1/O AEGOFv5Rryx+gpkZ6lFD4fyqUQ16zlGl2QRhUY/n1MIl9eZdLbyKzKD+V8ahnYy6fApvL8Bd+0J TmwYBq/uKK7fBuUrWmNdyDQ1iZXsFqIRQGH08+HklR2DE0NRda+IfriO3cV8QFDRY9+fX29mTSm bUCgpfnhrJ5RzohsKHI3bYx2PoxlrNUVnqixiMOMKPrF7dK57Mx/k92L7R8tj/5pTA0fRzUkIMT V4HqRNQ1aWq/d65GNfbTnRV2Ck4yGAdnzrnkM4+DGx/OQ1GV8oDH9tzzuv1v+gtHj7OwNO0UQCQ tpNwWekL0yAAGBDD4agii+gecvorn8+Q9b3aDXSvZIVxnTamu X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No X-TMASE-Result: 10--6.975800-4.000000 X-TMASE-Version: SMEX-12.5.0.1300-8.5.1010-24632.005 X-MDID: 1558604797-m-WQPGm0u9Ek Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: quoted-printable I was mostly puzzled by the double step. First find a parent device to Load= edImage that support NII. Rather than using that device we will scan all de= vices to see if any of them has the same NII protocol and if so we use that= one. I am not sure there is any advantage compared to just using the origi= nal parent device? In either way, the device path search using NII is fairly ingenious! On 22/05/2019 23:26, Michael Brown wrote: > On 22/05/2019 11:40, Tomas Pilar (tpilar) wrote: >> Yeah, I just AllocateCopyPool the static struct on heap for each device= . I can honestly see how one would assume that a protocol instance would ne= ver be installed on more than one handle, same as I assumed that using a st= atically allocated struct containing nothing but boilerplate info would als= o be fine. >> >> The whole NII and UNDI drivers vs. SNP drivers compatibility across OEM= s/IBVs and IHVs is a painful trash fire and this is just the last problem i= n a very long line of annoyances. > > Thanks for writing up the end result.=C2=A0 I can't immediately see any = more viable way for iPXE to determine the NII corresponding to the user's c= oncept of "the NIC from which I booted", but I'm open to suggestions. > > Thanks again, > > Michael > >=20 >