Jamie Lokier <lkd@tantalophile.demon.co.uk> wrote:
> You use the same initrd to tftp a second initrd.
[...]
>A userspace ELF binary needn't be much larger than the equivalent kernel
>code, if they're using the same API (syscalls).
[...]
>Not that it matters. A tftp client is a tiny program compared with the
>kernel itself.
Actually, my experience is that a tftp client of any sort is MUCH larger
than the equivalent http client!! (Don't look at wget, it's bloated.)
By the time you reimplement handshaking and flow control in the incredibly
primitive and slow tftp protocol, you have an order of magnitude more code
than if you had done it in tcp.
I made a ram disk setup that has just enough to bring up the network
and my httpget program. The httpget program is about two pages stripped,
including a usage string. It then proceeds to download all kinds of
extra stuff including a second ram disk and unpacks it with
httpget $NEXTURL | zcat |tar xvf -
I think tftp is the WRONG way to boot systems. If you look at how the
original diskless Sun systems tftpbooted, you will realize they had
the right idea. They tftp a teeny bootstrap program (less than 100k)
which has enough in it to NFS mount the root partition. Then they load
the KERNEL from the nfsroot.
Loading the kernel via nfs is probably a bit overboard, but it does help
boot speed a lot. On a busy network, loading a couple hundred K via tftp
can be very miserable. On the same net, transfering a couple of M via
http flies.
Steve
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Jan 15 2000 - 21:00:15 EST