On Thu, Sep 27, 2018 at 06:15:45PM +0800, Michael Chang wrote: > On Thu, Sep 20, 2018 at 02:01:08PM +0200, Daniel Kiper wrote: > > On Thu, Sep 20, 2018 at 06:38:07PM +0800, Michael Chang wrote: > > > On Thu, Sep 13, 2018 at 06:06:15PM -0600, Micah Parrish wrote: > > > > Hi, new subscriber here.? We have a problem with Grub 2 and its use of > > > > SNP > > > > instead of MNP.? Our UEFI driver for a network card parses the relevant > > > > DHCP > > > > options for iSCSI boot, generates an iBFT table, then gets closed by > > > > Grub > > > > when it opens the SNP interface. The driver removes the iBFT table as > > > > part > > > > of normal unload cleanup.? I think this should happen with the Tianocore > > > > UEFI reference driver as well.? The problem is often masked or does not > > > > occur when there are multiple network ports enabled.? It occurs with > > > > several > > > > different vendors NICs. > > > > > > > > Possible solutions I see: > > > > > > > > 1. Grub parses the DHCP options and creates its own iBFT. > > > > > > > > 2. Grub copies the already generated iBFT before destroying the > > > > interface. > > > > > > > > 3. Grub opens the network interface MNP instead of SNP. > > > > > > > > Although I am a neophyte at grub and UEFI development, I would like to > > > > start > > > > a discussion on possible solutions.? Has anyone else seen this? > > > > > > For possible solution 3, I managed to work out patch to use MNP but is not > > > polished, although it survived my testing. If you don't mind and willing > > > to > > > give it go I will post it here as RFC patch for review. > > > > That would be perfect. However, there are a few things worth mentioning > > here. > > > > The issue is never ending story. So, please look for relevant discussions > > in grub-devel archives and take them into account if it is possible/make > > sense. > > If you have any difficulties with finding them drop me a line. > > Thanks. I'm able to find those discussions in my mailbox. They are indeed very > helpful for me in catching up the problems. > > Moreover I found that Laszlo Ersek <ler...@redhat.com> already proposed an > approach which is very close to what I was working on, > > - identify NIC handles the same way you do now (I guess by enumerating > SNP interfaces) > - for each handle found, look for MNPSB *first*. > - If there is no MNPSB, then stick with the current strategy -- open > the SNP with exclusive access > - However, if there *is* an MNPSB, call the CreateChild() function to > extract a new MNP instance > - Use this MNP instance to send and receive packets. This MNP instance > will peacefully coexist with other (sibling) MNP clients.
More or less LGTM. > > Please do not drop SNP driver. I think that we should make MNP driver a new > > default and SNP should stay as a backup. Just in case. > > Yes. The patch has been worked the way you asked. I will try to take a look at it next week. > > Additionally, a few days ago I have started looking for people interested > > in the project. There are some. Hence, if you are going to take a stab at > > it I will ask them to do some reviews of your work. I will drop you their > > emails if they are happy to do so. > > Please feel free to CC them to the discussion. Will do. Daniel _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
