Marco Gerards wrote: > vincent guffens <[EMAIL PROTECTED]> writes: > > >>Marco Gerards wrote: >> >>>vincent guffens <[EMAIL PROTECTED]> 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. _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel