Slashdot Mirror

There's only one answer to that question. Wind River's slogan is "How Smart Things Think". Based on recent patent rulings, I'm pretty sure they've got the field covered with that slogan. Maybe that'll help them with this.

What about BSDi (or BSD/OS, or whatever they call it now)? Yes, it's "a BSD", but it's also proprietary in a sense, no?

It all depends on what part of the "agency" you're talking about. Certainly, there's a lot of push to move to MS on desktop-type systems.

But mission systems are a different matter. To start with, you're talking in some cases about systems that have been deployed for decades. What my company (and we're not alone) has been doing for the last 7 years is migrating these custom OS/HW systems to COTS platforms. In the sonar arena (think the sonar workstations in The Hunt for Red October), we have progressively moved the signal processing systems from custom systems to embedded (VxWorks and Mercury) to Solaris and SGI prototypes to Linux on Intel. Currently deploying systems are using Linux on Compaq Proliant 8500 8-way boxes. The next refresh will be to multiple dual-CPU P4 Xeon boxes communicating over Gigabit Copper Ethernet. Expect to see Itanium-based units in a couple of years. All of this is saving the Navy a lot of money while dramatically improving the capabilities of the fleet.

Do a quick Google search for Acoustic Rapid COTS Insertion.

And it's not stopping there. Plenty of other onboard systems, both in the surface and undersea communities, are moving from outdated one-of-a-kind systems to commodity hardware encapsulated in survivable enclosures.

Although, I would say around 80-90% of my VxWorks work is either PowerPC (PowerQUICC for data comm. applications) or StrongARM (everything else). MIPS is also pretty common these days.

But then again, VxWorks is pretty portable (not that I like it or WRS or anything.

Q. What is Wind Rivers philosophy on open source technology?
A. Wind River has always used open source technology. In fact, Wind River was the first licensee of the BSD network stack. The company supports the open source community and is committed to maintaining, distributing, and supporting FreeBSD. To spearhead that effort, BSDis Chairman of the Board Dr. Marshall Kirk McKusick, Vice President Open Source Technology & Chief Evangelist Jordan Hubbard, and Chief Technology Architect Michael Karels will join Wind River. Hubbard will continue to be responsible for the development and promotion of the FreeBSD OS as the release engineer for all FreeBSD products.

Wind River feels that FreeBSD is an open source OS based on a rich heritage and solid technical foundation and offers great technology and sensible licensing terms to its community. With FreeBSD, the open source and business communities can drive the individual and industry standards for a UNIX-based OS.

Q. What is Wind Rivers philosophy on open source technology?
A. Wind River has always used open source technology. In fact, Wind River was the first licensee of the BSD network stack. The company supports the open source community and is committed to maintaining, distributing, and supporting FreeBSD. To spearhead that effort, BSDis Chairman of the Board Dr. Marshall Kirk McKusick, Vice President Open Source Technology & Chief Evangelist Jordan Hubbard, and Chief Technology Architect Michael Karels will join Wind River. Hubbard will continue to be responsible for the development and promotion of the FreeBSD OS as the release engineer for all FreeBSD products.

Wind River feels that FreeBSD is an open source OS based on a rich heritage and solid technical foundation and offers great technology and sensible licensing terms to its community. With FreeBSD, the open source and business communities can drive the individual and industry standards for a UNIX-based OS.

Q. What is Wind Rivers philosophy on open source technology?
A. Wind River has always used open source technology. In fact, Wind River was the first licensee of the BSD network stack. The company supports the open source community and is committed to maintaining, distributing, and supporting FreeBSD. To spearhead that effort, BSDis Chairman of the Board Dr. Marshall Kirk McKusick, Vice President Open Source Technology & Chief Evangelist Jordan Hubbard, and Chief Technology Architect Michael Karels will join Wind River. Hubbard will continue to be responsible for the development and promotion of the FreeBSD OS as the release engineer for all FreeBSD products.

Wind River feels that FreeBSD is an open source OS based on a rich heritage and solid technical foundation and offers great technology and sensible licensing terms to its community. With FreeBSD, the open source and business communities can drive the individual and industry standards for a UNIX-based OS.

Actually, an even *better* choice would be one of the real-time OSes designed for this sort of thing. VxWorks (IIRC) comes to mind, theirs is the first OS to land on Mars.
Pathfinder == VxWorks on rad-hardened PPC.
See Here

Er, not exactly. I was accomplishing the same result in a TCP/IP driver for an FDDI board I wrote for VxWorks back in 1990.

Basically, you do at real interrupt level what you need to do there and stuff the functions that don't need to be done at real interrupt level into a ring buffer which then feeds a high priority task that fetches the function calls off its ring buffer one by one and executes them. As you exit your driver you call for a scheduling event. Because you can set hard, non-degrading task priorities, your cleanup task inevitably runs immediately. Other arriving messages are pretty much a don't-care (they interrupt the high-priority task), so long as you don't swamp your CPU with messages.

For example, suppose you get a device interrupt from your network board. At real interrupt level you check to see if a packet has arrived, and if it has, you stuff it into mbufs (actually, clusters). You queue the rest of the packet processing (e.g., the IP function table calls) for your high priority "cleanup" task, and you call high-level stuff like non-blocking select() in your application.

If you start off with a BSD-style driver, it's pretty easy to figure out what absolutely has to happen at real interrupt level and what can be thrown to a high priority task.

Being able to write our own driver came in very handy, because we used a broadcast message over FDDI as a synchronization event. All the applications signed up a function that did a taskResume on their main executive whenever that message arrived. The high priority task checked each incoming message to see if anybody had signed up to run something when it arrived, and if so, ran it (probably by sticking it into the ring buffer for the next-highest priority task -- can't remember any more -- maybe I just ran it then).

On a later version we got rid of some of the overhead by making the resumer function give a semaphore and had the executive wait for the semaphore at the bottom of its main loop. Since semaphores were queued, even if an application overran its time slot, it wouldn't lose a frame (within reason).

It's good to see that real time Linux seems to climbing up to where it can stand alongside the RTOSs, and, having had a source license for VxWorks, I can testify that having source on hand makes a real difference in a crunch, not only to fix bugs, but to figure out work-arounds. Nobody's documentation is ever good enough, and the source code never lies.

Rev. Bob "Bob" Crispen

"Something wonderful is coming. Do you want to join the exciting battle to change computing and topple the choking monopolies within the industry? :)"

And help us build our monopoly, centered around our proprietary OS!

Ok, so I work for WRS, but I still think these guys are trying to ride the fence and get some free apps for their proprietary OS...

Here's the direct URL:
http://www.wrs.com/products/html/jpl.html

This JPL mission really set the "standard" on what COTS hardware and software could do. It is the main reason why VxWorks was so widely adopted by the rest of the Aerospace industry.

-- Bryan "TheBS" Smith

1. Cygnus is used by other companies, too (Wind River Systems for one). If RedHat bought Cygnus, what would WRS do?
   
2. Why would anyone at RedHat have a problem with merging with Cygnus? I simply cannot see anyone getting their back up over this. Anyone have a good reason somebody would resign over this? Until I see one, that makes that part of the rumor suspect.

First of all, there's more than a single embedded systems market. There are truly low-end systems (think toaster thermocontrols) where a Unix-like OS is certainly overkill. On t he other hand, there's a very large market segment where a Unix-like OS is not overkill. Telecom switching equipment and industrial control panels fit into this category. In these segments, it's not unusual at all for your "small" computer to be a m68k, PPC, SPARC, or Pentium running at a respectable speed and having 4, 8, or even 32+ Mb of memory. This is the market space currently occupied by VxWorks ( Wind River Systems), pSOS ( ISI), LynxOS ( Lynx Real-Time Systems), VRTX ( Mentor Graphics), Chorus ( Sun), QNX ( QNX Software Systems), OS-9 ( Microware), and a whole bunch of others that I can't think of off the top of my head. Oh, yeah, and Windows CE.

I even know of folks who are using Solaris or AIX in this type of application. Not to mention the poor fools who are stuck with Windows NT for control and monitoring applications (don't laugh, it happens!).

Now, the majority of these real-time operating systems (RTOS) are POSIX-compliant, at least to some degree. Usually, this means that they implement the POSIX.1 APIs. So, except for the tasking and memory models, they look a heck of a lot like Unix/Linux. Some of them (LynxOS, QNX) are downright Unix clones (like Linux). All of them have TCP/IP networking available, all of them either already have Java support or have promised it Real Soon Now, lots of them even use gcc/gdb as their toolchain.

Given that, why not Linux? Margins tend to be sensitive here, so you'd really like to eliminate those per-cpu royalties that the commercial (I should say "proprietary", since MontaVista is obviously commerical) vendors charge. And (contrary to what some /.'ers have posted) uptime is critical in many of these applications. Long-term supportability and credibility is also critical, as many of these systems may have production lifetimes of years, and field lifetimes of decades. Customers already recognize the value of having access to the source code in these circumstances, and they tend to demand it from their software vendors (it is usually provided under NDA or escrowed).

Now, check out the founders of MontaVista. Jim Ready helped put together VRTX, one of the first commerically-successful RTOS's. Jerry Kirk founded Microtec, which is the dominant vendor of compilers and debuggers for embedded systems (the XRAY debugger is the most-used debugger in the embedded world). So I would guess these two ought to have a good understanding of how to put together a OS + development enviroment that would appeal to the RTOS market.

It looks to me like, between this and eCos, we're about to see The Cathedral and the Bazaar dynamic in yet another OS market.

While Linux is larger than Emacs, at least Linux has the excuse that it needs to be. -- Linus Torvalds