NIIBE Yutaka <[EMAIL PROTECTED]> 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
_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
