[lkml]   [2000]   [Jan]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Announce: initrd-tftp 0.1
    > 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


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:55    [W:0.020 / U:6.044 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site