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