From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1EwdX7-0002KQ-OT for mharc-grub-devel@gnu.org; Wed, 11 Jan 2006 05:48:51 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1EwdR9-0001ep-0J for grub-devel@gnu.org; Wed, 11 Jan 2006 05:42:40 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1EwdNv-0000rk-Uj for grub-devel@gnu.org; Wed, 11 Jan 2006 05:39:46 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EwdNp-0000qF-DF for grub-devel@gnu.org; Wed, 11 Jan 2006 05:39:14 -0500 Received: from [194.109.24.32] (helo=smtp-vbr12.xs4all.nl) by monty-python.gnu.org with esmtp (Exim 4.34) id 1EwdQR-0005hY-6n for grub-devel@gnu.org; Wed, 11 Jan 2006 05:41:55 -0500 Received: from localhost.localdomain (mgerards.xs4all.nl [82.92.27.129]) by smtp-vbr12.xs4all.nl (8.13.3/8.13.3) with ESMTP id k0BAb3NB099302 for ; Wed, 11 Jan 2006 11:37:03 +0100 (CET) (envelope-from mgerards@xs4all.nl) Mail-Copies-To: mgerards@xs4all.nl To: The development of GRUB 2 References: <8764ou330d.fsf@xs4all.nl> <43C30406.1060906@m17n.org> <877j982yjl.fsf@xs4all.nl> <43C47E0B.5020600@m17n.org> From: Marco Gerards Date: Wed, 11 Jan 2006 11:37:01 +0100 In-Reply-To: <43C47E0B.5020600@m17n.org> (NIIBE Yutaka's message of "Wed, 11 Jan 2006 12:39:55 +0900") Message-ID: <87lkxnoxte.fsf@xs4all.nl> User-Agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: by XS4ALL Virus Scanner Subject: Re: Networking status 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: Wed, 11 Jan 2006 10:48:36 -0000 NIIBE Yutaka writes: >> After that we can have a look at your code, see how well TCP >> integrates. What I am wondering is how complete it is, does it do >> retransmissions, slow start, congestion control, etc? > > Don't expect much. :-) It's a kind of hack. > > TCP is not a separate module, but it's actually HTTP+TCP. Client side > is assumed. You know, retransmissions, slow start, congestion > control, or path MTU discovery, all the things are only (moslty) > required by server side. I mean, my code doesn't implement this > because of no requirement. > > Actually, before I have implemented it, I also had thought we need > such functionalities for TCP. While coding it, I found that the > requirement for TCP is quite limited to download a kernel. > > All that client side is needed is to send SYN, and > > GET /somewhere/kernel/image HTTP 1.x > > and after that, it receive packets. Receiving a packet, it sends ACK. > It is server side which need retransmission, or other things. What if the request does not fit well into a single packet? I agree that we just basic functionality, but with the requirement that it still works properly according to the rules. > I say, it's a 'hack', because of it. It's not full featured software, > but it works well (for the purpose). Right. >> But if you have a small TCP implementations that works well, be could >> have a look at how to create a module out of it. It would also be >> very nice if NFS can be supported by GRUB 2 in that case, NFS is often >> available in the environments network booting is used and is capable >> of listing directory contents. > > I have an experience of implementing NFS for bootloader, it was called > sh-boot (for SuperH architecture). At that time, I took code from > etherboot, and it was not so difficult. Oh, cool. >> But at first I want to have the core functionality so people can use >> it as the base of their code, for example for driver support. At the >> moment TCP and HTTP, if possible, are not that important. > > I see. For GRUB, it's true. HTTP boot has been (and *is*) important > for our project. I can perfectly understand that. It sucks to install a TFTP server at a client. :-) >> Is FSIJ the company you work for and are they willing to assign their >> copyrights to the FSF? Perhaps it might be better to discuss this >> off-list? > > FSIJ, the Free Software Initiative of Japan, is non-profit > organization under Tokyo Metropolitan Government. It's a sister > organization of FSFE, Free Software Foundation Europe. Oh, I see. I didn't know that; great to hear about this initiative. > So, please feel free to take any portion of code if you think it is > useful. > > Currently, I'm not sure if you like my code, or my code is useful for > GRUB development. I just want to support your hacking. Sure. We can look at it at a later time, if you'd like. My first priority is getting GRUB at a state it is working and can replace and compete with GRUB Legacy. > If you will carefully select features, you don't need to be afraid of > the Dragon, {TCP,UDP} / IPv4 or IPv6 protocol stack. Because we don't > need full featured software, layer violation is your weapon, I'd say. :-) heh :) A bootloader has other requirements. For example, in my IPv4 implementation, I just set the don't fragment bit so I don't have to implement fragmentation. Surely there are some other things we can do like this. Too bad I could not find an RFC specially for firmware and bootloaders. -- Marco