Loading ...
Sorry, an error occurred while loading the content.

The future of the NSLU2-Linux project - your input is required!

Expand Messages
  • Rod Whitby
    Folks, We find ourselves at a juncture where the project s core team needs to decide where it is going to focus its developer resources going forward. The core
    Message 1 of 37 , Dec 29, 2005
    • 0 Attachment
      Folks,

      We find ourselves at a juncture where the project's core team needs to
      decide where it is going to focus its developer resources going forward.
      The core team is looking for your input (yes, all 5000 of you) to help
      us make a decision about which firmware should continue to be officially
      supported with binary images and pre-built package feeds, and which
      should be only maintained at the source code level by interested
      developers. Note that supporting a binary image and corresponding
      package feeds is a large effort, both in developer time, and in hardware
      and network resources. Please read this message carefully, and post
      your feedback to the nslu2-linux mailing list. If necessary, we may set
      up a poll to formally judge the response of the community.

      Firstly, there is Unslung. It is not in danger of being replaced by
      anything else, and will continue to remain and be updated as long as
      there are Unslung firmware developers (such as mwester and marceln who
      have recently stepped forward) and Optware/NSLU2 package maintainers (88
      of them registered on sf.net/projects/nslu, and Josh Parsons doing a
      great job of overseeing them) willing to support it. We have released 7
      Unslung beta versions (with Unslung 6.x in alpha testing now), and there
      have been over 15000 downloads of the latest Unslung-5.5-beta binary
      image. There are over 400 Optware/NSLU2 packages available today (not
      counting Unslung kernel module packages).

      If you really only care about using the Unslung firmware, then you can
      breathe a sigh of relief and stop reading here if you like :-)

      Next there is UcSlugC, which is designed to be the basis of "turnkey"
      flash-only NSLU2 applications (i.e. a dedicated pre-configured device
      for a particular purpose, with no hard disk or flash disk attached).
      John Bowler continues to develop this firmware variant, and I expect it
      will continue for as long as he is willing to support it. As there is
      no binary image available (it's meant to be the basis of such an image,
      not an image in itself), it's hard to judge how widespread the use of
      this variant is (as we can't just count downloads of the binary image).
      Note that it is not possible to use UcSlugC to debootstrap into Debian.

      Then we have the whole
      OpenSlug/DebianSlug/OpenDebianSlug/LeSlug/LeDebianSlug melting pot.
      This is the bit which we need to clean up and focus.

      Historically, we had OpenSlug which was defined to be a combination of
      the latest linux kernel, and the latest OpenEmbedded rootfs and
      packages, compiled for big-endian arm. We have released 4 OpenSlug beta
      versions (with OpenSlug 3.x in alpha testing now), and there have been
      about 2000 downloads of the latest OpenSlug-2.7-beta binary image.
      There are over 200 OpenSlug packages available today (there are actually
      over 3000 ipks in the feed, but over 800 of these are Perl modules,
      almost 300 of these are kernel modules, and locales form a large part of
      the rest), and there are many other OpenEmbedded packages which are
      candidate OpenSlug packages (they just have to be verified to build and
      then added to the feed list).

      Then Peter Korsgaard worked out how to get a slug to boot Debian in
      little-endian mode (albeit requiring a serial port and an external USB
      ethernet adapter). This technique could take advantage of the existing
      Debian arm port (and its 14000+ packages). We have no way of knowing
      how many people have gone down this path. The only problem was that we
      could not build the drivers for the internal ethernet interface in
      little-endian mode, which meant that you needed an external USB ethernet
      adapter to use this method. There was no simple single binary image
      released for this variant.

      Then Lennert Buytenhek ported enough Debian sarge packages to big-endian
      arm to enable "OpenDebianSlug" (which consists of installing the
      standard OpenSlug binary image, and pivoting to an external Debian
      rootfs). It is possible to boot OpenDebianSlug without a serial port
      and with no additional hardware required. Lennert and Derek Young have
      since built over 13000 packages from the Debian sarge (stable)
      distribution for big-endian arm (available at
      http://debian.nslu2-linux.org/sarge/debian). According to
      http://www.debonaras.org/wiki/Info/OpenDebianSlugUsers we have at least
      70 people using OpenDebianSlug.

      Then a number of people working together solved the little-endian
      internal ethernet driver problem, but nothing was done with that
      achievement for a while (other than proving it could be done and that it
      worked fine).

      Around that same time, we convinced a couple of influential Debian
      Developers to help us set up some machines to build the Debian sid
      (unstable) set of packages. The project donated two slugs for this
      purpose (Bob and Wendy) and those slugs have currently built just over
      10% of Debian unstable. It is unknown whether two slugs are enough to
      keep up with the continual changes in Debian unstable in the long run.
      Those packages can be found at http://armeb.debian.net/debian-armeb/ and
      can be used with OpenDebianSlug.

      Just recently I added the "LeSlug" variant to the mix. This is a
      little-endian version of OpenSlug (identical to OpenSlug in all other
      respects) which can debootstrap Debian sarge or Debian sid onto an
      external hard disk, and which can directly use the existing
      little-endian arm port of Debian (including all 14000+ packages). It
      does not require either a serial port or any additional hardware. If
      there was sufficient demand, a binary image could be made available in
      exactly the same way that the OpenSlug binary image is made available,
      and a LeSlug package feed has already been populated with all OpenSlug
      packages (and will continue to be automatically kept up to date with
      OpenSlug and UcSlugC by our build host).

      Thanks to a lot of work by John Bowler and Alessandro Zummo, we are
      currently pushing patches upstream to support the NSLU2 in the standard
      Linux kernel. We are also pushing patches for the Iomega NAS 100d
      device.

      I have recently started to engage with the debian-kernel and
      debian-installer teams, to work out how to incorporate NSLU2 support
      into the Debian kernel and the Debian installer. This is at an early
      stage, and we need to work out where we focus our efforts here too (i.e.
      do we focus on getting the nslu2 into the existing little-endian arm
      ixp4xx kernel, or do we try and get a new armeb architecture supported
      in Debian, or do we do both?).

      This email is long enough already, so please read and digest this, and I
      will follow up with another email giving a set of options for the future
      of NSLU2-Linux ...

      (In the interim, please feel free to discuss this here in the
      nslu2-linux mailing list)

      -- Rod (NSLU2-Linux Project Lead)
    • Adrian Day
      John, ... It s definitely not a kernel crash. It just kills the current ssh session. I m at work now but will attempt to delve a little deeper into this when I
      Message 37 of 37 , Jan 31, 2006
      • 0 Attachment
        John,

        On 1/31/06, John Bowler <jbowler@...> wrote:
        > From: Adrian Day
        > >Running 'ls -lR /' will lock a ssh session.
        >
        > Well, can you still ping the slug? (I.e. does it still
        > respond to ping?)
        >
        > I've never managed to lock a system (i.e. a hard kernel lock
        > or a crash) by doing that, or the pretty much identical
        > command "find /", and I do it quite a lot (it's a quick and
        > easy way of getting CPU load).
        >
        > What gets locked exactly? Assuming the ping doesn't respond,
        > does the power button work? What if you run a shell script to
        > toggle the disk 1 led on/off:
        >
        > while true; do echo -n 100 >/sys/class/leds/disk-1/brightness; sleep 1; echo -n 0 >/sys/class/leds/disk-1/brightness; sleep 1; done
        >
        > Does that keep going? (Running in another ssh session). What
        > happens when the LED is being made to flash from the kernel:
        >
        > echo timer >/sys/class/leds/disk-1/trigger
        > echo 1000 >/sys/class/leds/disk-1/frequency
        >
        > Does it lock up then? (That would indicate a kernel crash).

        It's definitely not a kernel crash. It just kills the current ssh
        session. I'm at work now but will attempt to delve a little deeper
        into this when I get home. I'm not alone - Jean Fabrice has
        experienced similar problems - I'd posted something about this a week
        or so back.

        Like I said, I'll spend some time looking into this in more detail.
        It's the least I can do compared to the considerable effort you and
        others have put into the slug.

        --
        Adrian
      Your message has been successfully submitted and would be delivered to recipients shortly.