Re: Networking status

[NIIBE Yutaka]

Thanks for your attention.

Marco Gerards wrote about my code:
> * Advantages
> - I assume it was tested a lot?
> - TCP+HTTP
> - DHCP, BOOTP and IPv6

* Disadvantages
  - non-modular implementation, assume ethernet
  - implementation which takes advantage of layer-violation

> 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.

I say, it's a 'hack', because of it.  It's not full featured software,
but it works well (for the purpose).

> We should at least support TFTP because many people have a TFTP server
> anyways.  For example people use PXE to load GRUB from the network
> (TFTP), so it would be convenient to use TFTP as well for loading the
> kernel.

Yup, for GRUB, I see.

> 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.

> 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.

> 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.

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.

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. :-)
--