From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1FcPao-00075O-2x for mharc-grub-devel@gnu.org; Sat, 06 May 2006 12:25:18 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FcPal-00074k-UB for grub-devel@gnu.org; Sat, 06 May 2006 12:25:15 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FcPak-000747-IQ for grub-devel@gnu.org; Sat, 06 May 2006 12:25:14 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FcPak-000744-Dj for grub-devel@gnu.org; Sat, 06 May 2006 12:25:14 -0400 Received: from [155.198.117.152] (helo=crumpet.cpn.ee.ic.ac.uk) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA:32) (Exim 4.52) id 1FcPbA-00077Q-3y for grub-devel@gnu.org; Sat, 06 May 2006 12:25:40 -0400 Received: from localhost ([127.0.0.1]) by crumpet.cpn.ee.ic.ac.uk with esmtp (Exim 4.44) id 1FcPai-0003LP-Ar for grub-devel@gnu.org; Sat, 06 May 2006 17:25:12 +0100 Message-ID: <445CCDE8.7000109@imperial.ac.uk> Date: Sat, 06 May 2006 17:25:12 +0100 From: vincent guffens User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013) X-Accept-Language: en-us, en MIME-Version: 1.0 To: The development of GRUB 2 References: <445CA646.7010704@imperial.ac.uk> <87ejz7b48h.fsf@xs4all.nl> <445CBCEE.8050906@imperial.ac.uk> <87ac9vb0a0.fsf@xs4all.nl> In-Reply-To: <87ac9vb0a0.fsf@xs4all.nl> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: pci support X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 May 2006 16:25:16 -0000 Marco Gerards wrote: > vincent guffens writes: > > >>Marco Gerards wrote: >> >>>vincent guffens 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.