Messages in this thread |  | | | Date | Sun, 09 Jan 2000 13:28:35 +0100 | | From | Hans de Goede <> | | Subject | Re: Announce: initrd-tftp 0.1 |
| |
As an embedded system developer myself, I would like to say that tftp-ing initrd is a good idea, and a usefull feature. Sure there are other ways, which don't involve the kernel, most of them however involve the mini-boot-loader most embedded systems have, which is different for each embedded system. So if it can be fixed in one uniform place why not?
And please don't give me the initrd attached to kernel image argument, that sucks from a maintainance point of view. What if each system needs a different initrd because the initrd contains some specific info? With tftp this is trivial.
Well I guess this shows once again that although a lott of people are using linux in embedded systems, embedded systems aren't taken seriously be the core kernel developers since they aren't sexy enough or whatever.
I'm sorry if I sound a bit harsh but sofar we have, a lott of very usefull embedded system patches which all haven't made it into the kernel, or there is talk of taking them out: -devfs -bootp (Yeah sure can be done through an initial ramdisk too, which can then do the tftp stuff too, which then can become the real initrd, which then can do some other stuff, sounds very much to me like it's very easy to break this scheme, and thus not nice to support) -initrd-tftp
So to build a kernel I need to apply devfs and initrd-tftp support and in the future hopefully someone in the embedded community will maintain a bootp patch if this is really removed.
Add to that: -m-sys doc driver (which can't be blamed on anyone but m-sys, for providing such a lousy driver) -uniform ide patches (some of these embedded devices have the weirdest ide chips, with strange ide emulating flash) -lm_sensors
Sure I'm becoming great in patching kernels, but does that make life easier for me?
And please don't start the all this can be done in userspace too discussion, that also goes for a lott of other features in the kernel, large file support for example, why not lett the libc library emulate it with multiple small files? Ah but thats bull because it would be so much slower/ pain to implement/is clearly not the way. Well from an embedded system point of view, having bootp and tftp done through a ramdisk attached to the kernel also clearly is not the way because: -the ramdisk will always be bigger then the in kernel code (both can be freed after usage, I'm talking storage here not runtime) -its a kudge, it's not nice and crispy -since it's a kludge it's a pain to maintain
Trust us (the embedded system developers) that the features we want are really usefull. If it could be done nice and crunchy in userspace, I would prefer it too, then I could easily maintain it myself and all would be happy. But the userspace solution is a kludge and will always be a kludge.
Now if you could find a significant number of embedded system developers saying, we don't need that that is kernel polution, then I would be impressed.
Regards,
Hans
- 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/
|  |