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

Re: [nslu2-linux] BE slug-os images are porkier WRT LE images.

Expand Messages
  • Mark Gross
    To be clear I never demanded anything. I just posed the question of why bother with the BE. You make some good academic justifications below. If we ve
    Message 1 of 13 , Jul 31, 2007
    • 0 Attachment
      To be clear I never demanded anything. I just posed the question of
      why bother with the BE. You make some good academic justifications

      If we've exposed a linker bug in the BE build then this thread is a good
      thing, but I don't think its fair to paint me as demanding anything.


      On Tue, Jul 31, 2007 at 12:43:03AM -0500, Mike (mwester) wrote:
      > On Monday, July 30, 2007 10:43 PM, Mark Gross wrote:
      > > > On Sunday 22 July 2007 17:57, Mark Gross wrote:
      > > > > On Sat, Jul 21, 2007 at 12:49:57PM -0500, Mike (mwester) wrote:
      > > > > > Yes, there are many valid reasons for big endian builds. Both
      > endians are
      > > > > such as?
      > > >
      > > > Network-native endianness is big. Running BE avoids swapping bytes to
      > get
      > > > higher throughput on constrained processors (IXP4xx are slow, remember).
      > > >
      > >
      > > I remember they are not too bad. (pretty big cache and what not) How
      > > about some data showing BE kicks LE's ass. Because, thats what it will
      > > take me to accept the argument that the hassle of getting the BE drivers
      > > working is worth the bother.
      > I'm confused now. Didn't you start this discussion asking why the BE images
      > exist? I don't recall that anyone was trying to force you to do anything at
      > all. It certainly sounds like you have your mind made up. That's fine.
      > But why are you trying to convince this community that we should drop BE
      > support? Don't answer that -- we'll continue to be endian-neutral, as

      I'm not trying to convince anyone, but I did want to know if I was
      missing something.

      > picking one over the other has been a battle fought over the same
      > blood-drenched turf for decades now. The ARM cpu runs in either, and as
      > long as people are willing to make Linux run on it in either mode, then
      > there's really no issue.
      > > Also, lets not forget that the same slugos-image under BE had zero
      > > blocks free, where the LE version of the same image has over 400 blocks
      > > free. That's something worth using even if the BE spcxxx driver is not
      > > BE safe.
      > >
      > > Why is the LE image smaller than the BE?
      > You're right, but your assumption is flawed.
      > The BE image is larger. The bulk of the difference seems to be due not to
      > endianness, but rather to an error in the build system somewhere.
      > /sbin/ldconfig is dynamically linked in the LE image, but *statically*
      > linked in the BE image. Of course that makes it much larger. There are
      > still some other executables where one is different in size from the other,
      > and perhaps if we ever run so close to the edge in terms of flash space I'll
      > investigate the 2KB size difference here and there that remains after the
      > ldconfig problem gets sorted out.


      > >From an instruction set point-of-view, there's no difference. So any
      > difference in data or executable sizes is based on application coding, which
      > can be fixed. But why bother? Just like the speed advantage for BE being
      > of little concern for most applications, a few KB here or there is also of
      > little concern for most applications. For every extreme case supporting
      > this endianness, someone else has another extreme case supporting the other
      > endianness. And so the battle continues.
      > Frankly, I think we should find and fix the ldconfig problem, but beyond
      > that I have no interest in fighting battles over a few bits/second here and
      > a few Kbytes there. I just want it to WORK, no matter what endianness is
      > selected.
      > > > > The software is fine. The camera driver works, but the camera doesn't
      > > > > understand BE.
      > > > > (It assumes LE)
      > > >
      > > > Thus, the driver _is_ broken, because it makes hard assumptions upon the
      > > > machine it is running on. Carefully written driver should cope with both
      > > > endianness, and other architecture-dependent issues (alignment, word
      > size
      > > > and so on...).
      > > >
      > >
      > > yeah, but if it works for LE then what is my motivation to fix the
      > > driver for BE operation?
      > Well, I think that it's clear that YOUR motivation is ZERO. That's fine,
      > that's why this is a hobby for most of us. Nobody has to do what they don't
      > want to do.

      Its a hobby for me too.

      > MY motivation for making something work in both endianness is the same
      > motivation I have to make it work on both x86 and ARM. I write better
      > software that way. It really is amazing how many errors and assumptions
      > creep into code when one writes (even subconciously) for a particular
      > architecture. For example -- the ppp driver in the kernel executes floating
      > point instructions. That's verboten in the kernel. But apparently this
      > slipped through, because the x86 hardware does it regardless of the kernel's
      > rules. Building the driver for ARM made that problem very apparent. There
      > are countless other examples where architectural items such as alignment,
      > atomicity, cache effects, and of course endianness have had latent problems
      > that could have been readily uncovered had the code been tested on other
      > architectures. Having ported the Via Velocity NIC driver from LE-only to
      > support both LE and BE, I am well aware of just how awful code can be that
      > is written with an assumption of a single architecture.
      > I am happy that I have a device -- the NSLU2 -- that can run the same OS and
      > software in both endianness to test my code upon -- it's a huge savings in
      > hardware, as well as a productivity enhancement. And like I said, it also
      > means that I don't have to be quite so ashamed of my code in peer reviews.


      > [snip]
      > > > Again, if the driver doesn't work with one endianness, then it is
      > plainly
      > > > _broken_. Not taking endianness (and word size, etc...) into account
      > when
      > > > writing a driver is a *major design flaw*.
      > >
      > > yes but as I'm not eager to fix the spaxx driver to work under BE
      > > systems I don't know what I will do about it.
      > >
      > Don't do anything about it. Nobody is pushing you to do anything. Again,
      > as I recall the thread, you demanded to know why people bothered with making

      I didn't demand anything. I just asked "why bother with BE".

      > a BE system, since it didn't seem to meet your needs. You got an answer,
      > which you rejected. No problem, it's a hobby. Nobody is ordering you to

      I was trying to see if there was something more than an academic
      argument. I didn't mean to "reject" them.

      > port anything to BE, or even use it. Likewise, we'll continue to support
      > both - despite some folks who don't agree with that.
      > Install SlugOS/LE, or Debian -- and enjoy it!



      > >
      > > --mgross
      > >
      > Mike (mwester)
    Your message has been successfully submitted and would be delivered to recipients shortly.