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