Charles Lockhart wrote:
Sorry, if I'm breeching protocol with crossover, please flame me privately. This article: http://www.embedded.com/story/OEG20021202S0052was 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
--MonMothaP.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.
pgpJxDwmh5Dpk.pgp
Description: PGP signature
