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/
This archive was generated by hypermail 2b29 : Sat Jan 15 2000 - 21:00:14 EST