Re: pci support

[vincent guffens]

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