Re: Networking status

[Marco Gerards]

NIIBE Yutaka <address@hidden> 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