[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: pci support

From: vincent guffens
Subject: Re: pci support
Date: Sat, 06 May 2006 17:25:12 +0100
User-agent: Mozilla Thunderbird 1.0.7 (X11/20051013)

Marco Gerards wrote:
> vincent guffens <address@hidden> writes:
>>Marco Gerards wrote:
>>>vincent guffens <address@hidden> writes:
>>>Hi Vincent,
>>>>I was wondering if there was still an interest in pci support as
>>>>discussed previously. That is a general interface exported by a module
>>>>such as
>>>Yes, that will make it possible to implement all kinds of drivers and
>>>make something like lspci possible.
>>>Sorry I still didn't start working on the networking stuff as planned.
>>>Scripting and other stuff occupies me longer than I originally
>>>expected. :)
>>Sure, no problem! In fact, I was wondering if it would be possible to
>>have a discussion about the overall networking strategy that will be put
>>in place for grub2 (and which is schedulled for the next release !).
> Sure!
>>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)

>>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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]