From: Marco Gerards <mgerards@xs4all.nl>
To: The development of GRUB 2 <grub-devel@gnu.org>
Subject: Re: pci support
Date: Sat, 06 May 2006 19:07:51 +0200 [thread overview]
Message-ID: <8764kjaxp4.fsf@xs4all.nl> (raw)
In-Reply-To: <445CCDE8.7000109@imperial.ac.uk> (vincent guffens's message of "Sat, 06 May 2006 17:25:12 +0100")
vincent guffens <v.guffens@imperial.ac.uk> writes:
>>>As I understand, supporting the etherboot drivers is no longer the
>>>primary option. As it is out of the question to have its own set of
>>>driver, the UNDI driver seems like a good idea. However, UNDI support
>>>would constrain significantly the design of the network stack. In
>>>particular, it defines a lot of structure such as dhcp header, ipv4
>>>addresses and so on. It also involves interruption while it was assumed
>>>previously that the interfaces would be polled.
>>
>>
>> Well, I do not really know UNDI. I had the impression it was able to
>> send and receive raw ehternet frames. Which is what I want, nothing
>> more and nothing less.
>>
>> At interrupt time, you can store the frames in a queue so they can be
>> polled at a later moment. Or the design should be changed so
>> interruptions can be supported. That's not a big issue I think.
>
> yes, you can use it with a polling mechanism as well. But UNDI has a
> much more complex API then just sending and receiving raw frames. You
> have API calls to request a file via tftp or even mtftp, get the
> information received from the dhcp server, send UDP packets and so on.
> It would be waste, I think, to go through the work of supporting UNDI
> and not getting the entire benefit which would require a strong
> coordination between the PXE/UNDI code and the net code of grub2
> (through the PXE specification)
The less we rely on PXE code, the less bugs we have to deal with I
think. Most firmware implementations are full of bugs, I don't expect
the PXE implementations are an exception.
Ad besides that, we need full networking support anyways. For example
for the PPC port.
>>>There is also the option of calling etherboot from grub2, which seems
>>>quite appealing but I think I don't really quite get that.
>>
>>
>> Is that etherboot specific or is that the case for every UNDI
>> implementation?
>
> well, I just mentioned the idea that was raised by Okuji in an earlier
> post. That is what I meant and I don't know if I understood properly but
> etherboot implements a PXE stacks. So if a network card does not support
> it, it would be possible to use etherboot as the PXE stack. But I don't
> know how it would work. When etherboot is located in an extension rom,
> then maybe the bios can scan it and use it ? I am not sure but I have
> sent the question to the etherboot mailing list, I am waiting for some
> comments.
Please let me know.
--
Marco
next prev parent reply other threads:[~2006-05-06 17:05 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-05-06 13:36 pci support vincent guffens
2006-05-06 14:08 ` Vesa Jääskeläinen
2006-05-06 14:46 ` Marco Gerards
2006-05-06 15:12 ` vincent guffens
2006-05-06 16:12 ` Marco Gerards
2006-05-06 16:25 ` vincent guffens
2006-05-06 17:07 ` Marco Gerards [this message]
-- strict thread matches above, loose matches on Subject: below --
2008-01-28 14:03 PCI support Marco Gerards
2008-01-28 17:25 ` Robert Millan
2008-01-28 18:32 ` Marco Gerards
2008-01-28 19:08 ` Robert Millan
2008-01-29 8:40 ` Marco Gerards
2008-01-30 17:57 ` Marco Gerards
2008-01-30 18:44 ` Robert Millan
2008-01-30 20:08 ` Marco Gerards
2008-01-30 22:01 ` Robert Millan
2008-01-30 22:17 ` Marco Gerards
2008-01-30 22:25 ` Robert Millan
2008-01-31 8:51 ` Marco Gerards
2008-01-31 11:05 ` Robert Millan
2008-02-02 15:39 ` Marco Gerards
2008-01-30 19:40 ` Yoshinori K. Okuji
2008-01-30 20:07 ` Marco Gerards
2001-10-12 18:38 Kevin Fry
2001-10-12 19:09 ` Dan Taylor
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=8764kjaxp4.fsf@xs4all.nl \
--to=mgerards@xs4all.nl \
--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.