[luau] another interesting thing I found on another list

MonMotha monmotha at indy.rr.com
Wed Dec 4 16:46:01 PST 2002


Charles Lockhart wrote:
> 
> Sorry, if I'm breeching protocol with crossover, please flame me privately.
> 
> This article:
> 
> http://www.embedded.com/story/OEG20021202S0052
> 
> was causing a bit of anger and disgust on another list, and I could 
> pretty much see why.  This guy has 15 years of working experience with 
> vxWorks, none with embedded Linux, or even with Linux in general as far 
> as I could tell.
> 
> His complaint was that embedded Linux is touted as being free, but it 
> wasn't.  But generally he and his team made a bunch of bad choices in 
> terms of system design, and he was publicly penalizing embedded Linux 
> for these.
> 
> Example, he complained that while e-Linux is touted as being free, he 
> had to pay a consulting group a lot of bucks to port the kernel to the 
> uP that they'd selected.  I think an obvious no-brainer would have been 
> to choose a uP that's already supported rather than taking the risk of 
> going off into the great unknown.

This is a given.  Porting the kernel to a new archetecture is NOT easy 
at all.  It is a long-time goal of mine to port it to some hardware I 
may or may not make in the long-term :) as a learning experience.  I 
certainly wouldn't want to put any money on it, nor would I have much 
faith in said brand-new port.

Stick with the knowns: ARM, SH, MIPS, PPC, CRIS, etc.  These ports are 
maintained by a large group of individuals (often including at least one 
corporate "sponser") and are known to be in working order, and if 
they're not, you can probably find someone to help you with it.  I've 
certatinly seen this with ARM.

> 
> Other complaints that he made:
> 
> They had to re-write some Linux drivers because again, they weren't 
> supported for the uP they chose.

Part of porting the kernel since with a monolithic kernel design, 
drivers are essentially part of the kernel.

> 
> The consulting group ported the kernel for some reference design that 
> was available for the uP, and so they then had to spend time(=money) 
> cusomizing for their custom hardware design.

Isn't this part of any embedded project?  Rarely is a reference design 
used and there's always at least some drivers that need to be written.

> 
> While I agree that in some ways Linux dev is a bit like trying to hit a 
> moving target, the problem was amplified because they kept recieving 
> kernel updates from their consultants, and they kept updating their 
> kernel rather than freezing it, resulting in having to rewrite some of 
> their driver code multiple times.  Again, the no-brainer I think would 
> have been to focus on a snapshot of what they needed, and only fold in 
> kernel mods that would fix problems.  Plus, in my mind I associated this 
> as a problem with the consultants, not e-Linux.

Creeping featurism is a dangerous thing.

> 
> The author had to recompile gcc as a cross compiler for his uP, which he 
> thought was a pain.

Oh please, this has to be done with any archetecture, unless you want to 
compile natively (which is often slow and requires a native 
compiler...which as to be built using a cross compiler at some point!). 
  I agree (having bootstrapped ARM toolchains myself) that it is a big 
pain, especially without an autobuild system, but it's just something 
that has to be done.  Had he chosen a more common archetecture, a 
toolchain probably would have been available!

> 
> The author had a harder time getting some things working using e-Linux 
> than he did with vxWorks.  But they were things like applications to 
> convert the kernel + applications into a ROMable image, stuff that I've 
> seen available on the net before.  My thinking was that if he had 15 
> years worth of experience with Linux these things would have been just 
> as easy.

I build bootable jffs2 images many times daily...as a hobby.  It's not 
too tough to make the filesystem up, then run mkfs.jffs2 on it (assuming 
you're using jffs2...which provides read/write access to flash, a 
feature many other embedded OSes lack).

> 
> Anyway, I generally like reading about peoples experiences with embedded 
> Linux and Linux as applied to science, so I apreciated the article, I 
> just wish it would have been more objective, and not so much playing the 
> blame game.  One point he made was that they failed to make the date for 
> demoing the product to their customers, and he pretty much intimated 
> this was e-Linux's fault, which I thought was pretty bogus.

I agree.  See above, the guy made some bad choices that made his 
experience miserable.  If you want to sail into the great unknown with a 
new uP, be ready to get bitten by some new sea-creatures.

> 
> -Charles
> 

--MonMotha


P.S.  Be aware that this thread could very easily turn into a 
flame-fest.  I've tried to keep from encouraging that, but if anyone 
interprets any of my comments as flamebait, please send them to me 
privately, or better yet, send them to /dev/null, just please don't 
allow a flamewar to develop on the list.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 252 bytes
Desc: not available
URL: <http://lists.freesoftwarehawaii.org/pipermail/luau-freesoftwarehawaii.org/attachments/20021204/34e498b2/attachment-0001.pgp>


More information about the LUAU mailing list