Messages in this thread | | | Subject | Re: Announce: initrd-tftp 0.1 | Date | Sun, 9 Jan 2000 13:27:22 +0000 (GMT) | From | Alan Cox <> |
| |
> 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.
I still don't buy this
> 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 spent several years working on embedded systems for Sonix and 3com. Been there, done that. Putting stuff in kernel space that can be elsewhere is normally a bad idea - NFSroot is another example.
If you put tftproot in the kernel then dhcpd, netware root, smb root, ipx based RPL, 802.2LLC based RPL and all the rest will follow. If people fix any rough edges on the initrd handling all of these, and combinations will come out ok in user space
Second thing; tftp is almost away done wrongly for an embedded system. Unless you are protecting your data stream with a shared secret between your boot loader and your main system it requires you only deploy such devices on a trusted lan segment firewalled from the main network as tftp has no credible security - its meant to be a trivial protocol.
> -m-sys doc driver (which can't be blamed on anyone but m-sys, for > providing such a lousy driver)
So use the non m-sys driver.
> -uniform ide patches (some of these embedded devices have the weirdest > ide chips, with strange
Andre pushed the key patches for sandisk related flash (its not weird by the way its a standard with a real specification and the like and multivendor)
> -lm_sensors
On an embedded box that is one I'd userspace simply to get it very small when possible. And 2.3.3x has the i2c bus changes needed to support lm-sensors and the newer tv cards switched over to the newer i2c bus drivers, so thats rubbish on your part too.
> -the ramdisk will always be bigger then the in kernel code (both can be > freed after usage,
And the point is ?
> -its a kudge, it's not nice and crispy
Actually its clean, the kludge is putting chunks of user crud into kernel space.
Alan
- 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/
| |