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. > 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? -- Marco _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
