“One of the most important considerations in choosing an operating system for a new embedded platform is how long it takes to port the operating system to the hardware. If your hot, new product’s hardware is six months ahead of the curve, but it takes you six months to port the software, you’ve lost your hardware advantage.” Alistair Crooks, engineering director at Wasabi Systems, writes for EETimes.
While NetBSD gets little fanfare, here’s the role it’s particularly well suited for, as this was a design goal.
I think folks do not necessarily understand the complexities of porting something like an OS to a different architecture and therefore may not quite appreciate what something like NetBSD has to offer.
It’s just an advertisment by wasabi (the owner of netbsd) claiming that they are more posix compliant than linux (even though the word posix was not present in the paper).
However compare with the real embedded OS’es like lynx or qnx (both of which are actually posix CERTIFIED), the argument just falls flat.
If your hot, new product’s hardware is six months ahead of the curve, but it takes you six months to port the software, you’ve lost your hardware advantage.
There is assumption that competitors catch up in hardware in 6 months and would have software for it instanteneously. Kind of stretch in the logic. It would be intersting to get market analysis on what OS is dominating in embedded world.
I doubt seriously that it’s NetBSD.
I saw the article on a slightly different angle. While it’s true that it definately look like promotional material, there is truth and lessons to be learned in that article.
1.) it’s not because you are using a portable language that your code is portable
2.) it’s not because you write portable code that your drivers can be ported without a re-write.
Solution for (1) is to know how a platform can affect the language you are using and try to avoid assuming anything that could tie you down to a single platform or to a small subset of platforms. Examples are word sizes, alignement, byte ordering. Pretty much like detailed in the article.
Solution for (2) is more of an operating system design, how to properly abstract the hardware so that you can avoid re-writing code when porting to a totally different hardware architecture. Again, the article sheds some light on how to proceed, by abstracting buses, byte ordering, etc.
The article also points out various flaws in the Linux kernel that should be addressed in the near future in order to help in Linux’s portability.
I think it’s a good read, even if you are planning on programming for a single platform and for a single operating system. Many things said in there are good to incorporate in your daily programming practice.
Personally, I’m going to study those bus abstractions and see what I can pull out of there for my own os. Thanks for the article Alistair.
Well, certainly NetBSD isn’t used that much in the embedded world by now, but this is mostly due to the Linux hype.
The article only states some advantages of using NetBSD, namely modularity which allows you to customize the thing.
Of course the author as a Wasabi employee is partial, but that doesn’t make his arguments any worse. Also, it should be mentioned that Wasabi certainly _don’t own NetBSD_! NetBSD is a totally free OS, while Wasabi provide services for it (and have some people do impressive development on NetBSD).
Regarding POSIX compliance — I dont think it matters for embedded systems. Actually NetBSD has very-high quality man-pages (IMHO) and these should make you job developing easier. If you can afford to read the POSIX standard (time- and money-wise), well…
But most people fare nicely with a well-documented system.
And certainly I don’t like QNX as a system at all, I tried it maybe a 2 hours…
>>>>Regarding POSIX compliance — I dont think it matters for embedded systems.
The QNX’s of the embedded world aren’t cash rich with IPO’s from the internet bubble boom. If they spent that much money, time and effort of POSIX certification — then it pretty much tells you that POSIX matters in the embedded world.
I think QNX applied for POSIX compliance to get more credibility. In a world where everything is Windows or Unix, it’s hard to draw people to your platform, even if it’s much superior. So by being _officially 100%_ POSIX compliant, QNX can get customers from the Unix world as well.
Still Linux and NetBSD maybe aren’t 100% POSIX compliant, and at any rate not officially anyway, but people use them because there’s reasonable documentation out there (though I dont know if NetBSD is being seriously used in the field already).
>>>>I think QNX applied for POSIX compliance to get more credibility. In a world where everything is Windows or Unix, it’s hard to draw people to your platform, even if it’s much superior. So by being _officially 100%_ POSIX compliant, QNX can get customers from the Unix world as well.
Except that Unix and Windows doesn’t play any significant roles in the embedded world (even DOS has a bigger market share in the embedded market) — your argument falls flat. Why would QNX wants to attract Unix customers when Unix is not used in embedded market.
If you want credibility, the lynx and the qnx’s are certified for FAA and nuclear power stations — the 2 hardest certifications in the world. There is no credibility added for POSIX — the microsoft’s, beos, linux dilutes the meaning of POSIX compliance.
The US Government requires that all operating systems purchased have some sort of POSIX requirement. That’s why Windows NT, for example, has a useless POSIX library included.
That having been said, this article was not about POSIX compatability I don’t think anything in the article was trumpeting NetBSD’s POSIX complience; it completely talked about it’s device driver abstraction and other *real* things that make it portable, along with a lot of details that could help other operating systems for someone who wants to implement or improve other operating systems or who wants to use NetBSD as an easy to port solution for a platform needing an OS.
What he failed to mention was NetBSD’s usefulness outside of the embedded sphere; I’m running it on a i386 because I find it elegant, and it has excellent source code and documentation. Of course, Wasabi seems to be primarily an embedded company, though it contributes *a lot* to NetBSD as a whole; much as Red Hat, SuSE, IBM, and others employ programmers who contribute to Linux.