#include <hallo.h>
>> > isn't one), but do have the ability to load and execute a block of code
>> > (the kernel) from the network. This patch allows the kernel, once it's
>> Then they can support an initrd. You can have the initrd compiled into or
>> appended to the kernel image.
> That means you have to write a mini boot loader which knows how to do that
> for each architecture (initrd-tftp is architecture independant), and
> you're subject to whatever arbitrary limits in image size the firmware
> might have. It also means having to rebuild the kernel image file whenever
> you make a modification to the contents of the initrd. It's also needs
> more memory because you have to load the initrd into the initrd space at
> boot and then decompress/copy it into the ramdisk, rather than loading it
> directly into the ramdisk (which would matter if you had a 6MB RAM disk on
> an 8MB machine or something like a lot of embedded systems).
Who says that the embedded system has to do that in his own memory? You
need a server from which you get the data and store it back. That server
can also do that work for the embedded system. You already need to hack a
script or so for doing the work, why not hack a "client server" solution
in which the embedded system tells the server what has to be done. The
Server should enough memory and storage place for including all things
necessary. (To be continued...)
IMHO here is somebody "inventing" a problem where no one is.
Bis denn
-- Mein persoenliches (deutsches) Linux Lied: "Abenteuerland" von PUR- 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:13 EST