public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Michael Brown" <mcb30@ipxe.org>
To: devel@edk2.groups.io, tpilar@solarflare.com,
	Laszlo Ersek <lersek@redhat.com>
Subject: Re: [edk2-devel] iSCSI and iBFT
Date: Thu, 23 May 2019 11:35:14 +0100	[thread overview]
Message-ID: <209c21f7-3989-37e5-f97c-49908cda8300@ipxe.org> (raw)
In-Reply-To: <e066fc1a-93ef-69eb-a9c5-c116418ccb64@solarflare.com>

On 23/05/2019 10:46, Tomas Pilar (tpilar) wrote:
> I was mostly puzzled by the double step. First find a parent device to LoadedImage that support NII. Rather than using that device we will scan all devices 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 original parent device?

The problem is that we may need to attach to a parent of that original 
parent device.  The relevant commit in iPXE is:

   http://git.ipxe.org/ipxe.git/commitdiff/4c5b7945c

[efi] Use the SNP protocol instance to match the SNP chainloading device

Some systems will install a child of the SNP device and use this as
our loaded image's device handle, duplicating the installation of the
underlying SNP protocol onto the child device handle.  On such
systems, we want to end up driving the parent device (and
disconnecting any other drivers, such as MNP, which may be attached to
the parent device).

Fix by recording the SNP protocol instance at initialisation time, and
using this to match against device handles (rather than simply
comparing the handles themselves).



That commit predates the iPXE NII/UNDI driver and so refers only to SNP, 
but the same principle is applied for NII.

Michael

      reply	other threads:[~2019-05-23 10:35 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-20 15:56 iSCSI and iBFT Tomas Pilar (tpilar)
2019-05-21 14:54 ` Tomas Pilar (tpilar)
2019-05-21 19:47   ` [edk2-devel] " Laszlo Ersek
2019-05-22  9:55     ` Tomas Pilar (tpilar)
2019-05-22 10:19       ` Laszlo Ersek
2019-05-22 10:40         ` Tomas Pilar (tpilar)
2019-05-22 22:26           ` Michael Brown
2019-05-23  9:46             ` Tomas Pilar (tpilar)
2019-05-23 10:35               ` Michael Brown [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=209c21f7-3989-37e5-f97c-49908cda8300@ipxe.org \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox