From: "Vladimir 'φ-coder/phcoder' Serbinenko" <phcoder@gmail.com>
To: grub-devel@gnu.org
Subject: Re: RFC: UEFI/PXE and emulating grub-legacy-uefi-hacked behaviour
Date: Wed, 25 Apr 2012 10:31:28 +0200 [thread overview]
Message-ID: <4F97B660.7050102@gmail.com> (raw)
In-Reply-To: <CAHonLzhmt8U_H0vk3UPg-5pmsE3TdNQMi1OdaRg+0Qe53gUY7g@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1238 bytes --]
On 25.04.2012 02:16, Richard Chan wrote:
> 5. I have looked at the existing GRUB net+efinet stack. During my
> simple testing I have to be unaable to trigger the code path where
> grub populates the grub_net_structure from the UEFI PXE code. This
> occurs in grub_efi_net_config_real() in
> grub-core/net/drivers/efi/efinet.c.
The information from EFI network is used only if efinet is embed in
grub.efi. Otherwise you have to call net_bootp manually
> When I do
> grub> insmod efinet
> grub> net_ls_cards
That's not what is expected. Could you try debug where
grub_efinet_findcards in efinet.c stopped?
> grub> net_ls_addr
> I cannot see any information from the PXE boot (i.e. I have booted
> grub using UEFI PXE and I expected the efinet structures - at least
> one of the cards - to be populated from PXE).
>
> Nevertheless, since the UEFI/PXE stack works independently of Grub,
> would it be ok to bypass the whole grub/net/drivers infrastructure and
> use UEFI directly, as what grub-legacy currently does?
No. You basically say "code A has a bug, let's throw it away and write
code B, which will have other bugs". Such approach is unmaintainable.
--
Regards
Vladimir 'φ-coder/phcoder' Serbinenko
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 294 bytes --]
next prev parent reply other threads:[~2012-04-25 8:32 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-25 0:16 RFC: UEFI/PXE and emulating grub-legacy-uefi-hacked behaviour Richard Chan
2012-04-25 8:31 ` Vladimir 'φ-coder/phcoder' Serbinenko [this message]
2012-04-25 15:59 ` Bean
2012-04-25 17:57 ` Seth Goldberg
2012-04-25 20:20 ` Richard Chan
2012-04-25 20:38 ` Vladimir 'φ-coder/phcoder' Serbinenko
2012-04-27 5:41 ` Richard Chan
2012-04-25 20:21 ` Bean
2012-04-25 20:39 ` Vladimir 'φ-coder/phcoder' Serbinenko
2012-04-26 2:23 ` Bean
2012-04-26 4:10 ` Seth Goldberg
2012-04-26 4:22 ` Bean
2012-04-26 4:59 ` Seth Goldberg
2012-04-26 11:46 ` Bean
2012-04-26 17:10 ` Seth Goldberg
2012-04-27 1:50 ` Bean
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-all 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=4F97B660.7050102@gmail.com \
--to=phcoder@gmail.com \
--cc=grub-devel@gnu.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.