[Top][All Lists]

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

Re: pci support

From: Marco Gerards
Subject: Re: pci support
Date: Sat, 06 May 2006 19:07:51 +0200
User-agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.4 (gnu/linux)

vincent guffens <address@hidden> 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.


reply via email to

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