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
> > > 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
> 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
> > > > 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
> > > 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.
> > > Again, if the driver doesn't work with one endianness, then it is
> > > _broken_. Not taking endianness (and word size, etc...) into account
> > > 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)