NIIBE Yutaka <[EMAIL PROTECTED]> writes: > FWIW, I developed a boot loader for M32R architecture which supports > HTTP download: http://www.gniibe.org/software/m32r-g00ff-20060107.tar.gz > > It is single threaded, I mean, with polling (or busy loop). It's only > for boot loader. > > It supports both of IPv4 and IPv6. ARP, Neighbour discovery of IPv6, > UDP, DHCP, DHCPv6, DNS, and HTTP/TCP is supported.
Perhaps we can have a look how to integrate this with my code, do you think it is possible? Some advantages and disadvantages of both of our works. Please correct me if I am wrong: My code: * Advantages - Already well integrated with GRUB 2. - Already designed to be modular and support more than Ethernet. * Disadvantages - Not complete yet (no DHCP, BOOTP and TFTP, although they are all quite trivial I think). - Not tested a lot yet. - Support for testing by using TAP. Your code: * Advantages - I assume it was tested a lot? - TCP+HTTP - DHCP, BOOTP and IPv6 >From the looks the structure looks similar so I assume it can integrate well. Besides that my focus is on Ethernet, portability, IPv4, UDP and TFTP. All this is mostly implemented and I think it is better I commit these things first. I'd like IP+UDP to be in one module and to implement BOOTP/DHCP, TFTP, etc. on top of that in separate modules. 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? Are you willing to work with me on this? > I know that TFTP is most popular for booting through the net. But, > for our purpose (development of embedded system), HTTP is better. > People don't run TFTP server normally. HTTP server is common, and put > a kernel on the web is easy thing to do. 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. 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. 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. > If my code will be considered useful, I could transfer the copyright > to FSF (currently it's copyrighted by FSIJ). 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? Thanks, Marco _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
