Cygnus Announces "Embedded Linux Solution"

While I was unaware that this was even a problem, Cygnus Solutions announced EL/IX API which is "...a major step to pre-empt the fragmentation of embdedded Linux..." Essentially, it's an open source, configurable API that lets developers create software for embedded devices running Linux or Cygnus "eCos" OS. Standardization is a good idea, I suppose, and embedded seems to be the way the wind is blowing.

Might be offtopic

[PsychoSpunk]

This reply is not effectually a response to the article, but more to solicit a response who works in the embedded systems field.

I am writing a document for a class (thankfully, my last english class) which requires me to contact an "expert" in the field I am discussing.

I find embedded systems to be fascinating and would like to contact anybody who has done development in the field.

Moderators I implore you not to knock my score, and potential "experts" I would ask that you either reply to this message or to email mf40467
in the domain of swt.edu so I can begin to ask questions pertaining to my paper's topic.

Thanks.
Mike

Yes, it is POSIX

[Zach Frey]

(answering my own question ...)

Finally found some content at Cygnus' EL/IX page [cygnus.com], and it appears that this will be POSIX based.

It's going to include most of the base Unix API, the real-time extensions, POSIX threads, the ISO C library, and BSD sockets (minus STREAMS). I assume that the BSD sockets support means that eCos will have a TCP/IP stack, which another poster mentioned as a problem with eCos.

And, one of the design criteria is to make EL/IX a subset of the API that is already available on Linux, so this will not involve any Linux enhancements.

Go Cygnus! :^)

Re:Ecos/Linux embedded not suitable - GPL sealed f

[devphil]

Granted it's been years since I played with Linux, but when building a kernel we had to "make config," or something similar, which would ask the user what to include in the kernel (while remembering choices from last time, etc, etc).

I'm assuming that today's distributions still do that, in some form or another. Why not just disable support for just about everything? It's what I used to do when building customized rescue diskettes. The resulting kernel got pretty small.

(Disclaimer: I don't know jack about embedded systems, and I don't know whether this process would bring the size down /enough/ to be useful. But you used to be able to rip a significant amount of stuff out of the kernel.)

The GPL is another problem altogether... :-|

Re:Ecos/Linux embedded not suitable - GPL sealed f

[AaronW]

Linux still does this, however many pieces (i.e. the filesystem) cannot be removed. In fact, if we removed all the stuff we don't need there'd be almost nothing left. We don't need SMP support. We don't need a filesystem. We don't need security. We don't need virtual memory. We don't even want preemptive multitasking (our product uses cooperative tasking). The problem with Linux is that it's difficult to remove these pieces, since thing like the filesystem, virtual memory, and preemptive multitasking are integral to the operating system.

Linux was not designed to be a RTOS. A RTOS does not necessarily make the OS good for general purpose operation. I mean, a network switch, router, toaster, etc. has far different requirements than a PC. Real-time operating systems are more than just special scheduling. Often they're designed to be quite compact and have extremely modular functionality. They run in things like your VCR, DVD player, router, intelligent hub, palm pilet, etc. They are designed for very tight memory constraints. Some operating systems are very primitive, such as what runs in a VCR or your keyboard.

In our environment, for example, without all the things listed above, we use a unified memory space. All processes share the same memory space. We don't care about virtual memory since if a process dies it's probably catastrophic since most of the processes are interdependent.

In our product, a real-time process is often more like a TSR in that it is event driven and communicates with other processes via events.

Granted, there are places where Linux can work quite nicely, for example tivo [tivo.com], which, I must add, is a really cool product (and they'll burn a Linux CD with their kernel modifications upon request). But that's a different ballgame where a filesystem is important.

Cygnus

[scumdamn]

Cygnus is one of the premier open source companies. We're lucky to have those guys on our side. Before the Open Source phenominon took off the software company landscape was looking pretty bleak as far as ethics and idealism went, but now there are so many good companies producing high quality software, making money, and not selling out. It's truly heartening to see.
Thanks, Cygnus, and keep the software coming!

Fragmentation

[Anonymous Coward]

The problem is that most embedded systems has no MMU. I know Axis [www.axis.se] have made some linux implementations and I have seen other local companies advertising about a job to deal with these problems.

Writing programs without an MMU to rely on is probably dependent on strict use of a good memory management system, and from what I have heard this is the main problem with linux and these applications.

Patrik Carlsson

Re:Not so good

[J.Random Hacker]

I think that you mis-read the dispute. I understood the issue to be one of continued stability on the one hand (rms, et.al.) vs inclusion of new optimization strategies, better implementation of some increasingly important C++ features (and tracking the C++ standard), and the addition of some new front-end languages that required some back-end support on the other hand. What was appeared to be happening was that the changes to support things like a non-broken template instantiation mechanism were not being included in the 2.7.x releases, and 2.8 was taking *way* too long (18 months or so at the time of the initial fork IIRC).

egcs gave the folks who wanted the new features a place to hack, and check their results. The egcs team has done such a good job with these enhancements, that they have become the GCC maintainers.

I view this as a Good Thing.

Let us judge this announcement on its technical merit, and on its openness and free(dom)ness, and leave personalities at the door.

Re:Rob is an idiot

[alonso]

Who is an idiot?
I could say that you are an idiot, but this is stupid and unproductive! Do you need the /. code? Ask for it! And thanks Rob for his work!
I like /. and I would like to thank everyone involded in it!

Re:Not so good

[tiemann]

Fooey! Here's my rebuttal:

1. The relationship I have with Stallman is cordial. The last time he visited California (during the Linux World show in August), he called me, ask for help to support a cause, and I answered the call with an endorsement from Cygnus. Note that I could have wimped out and done nothing, or I could have said "it's ok to use my name, but not the name of Cygnus", but I went the extra mile to get our CEO and CFO to agree to participate in this action.
2. It's very easy to talk a good free software story when you're preaching to the converted. Stallman and I share the experience of talking not to the converted, but to the skeptical. Stallman has taken one approach, that of the unapologetic idealist. This approach tends to polarize opinion and result in reporting that either brands him a saint or a lunatic. I take the approach of the unapologetic pragmatist, and that tends to lead to reporting that acknowledges the merits of the case. Either way, Stallman and I catch a lot of flames, but we catch them for different reasons. I'm glad that Stallman has established the position that he has...it enables me to work the field from a different angle.
3. The splintering of the GCC compiler was due to the fact that Cygnus was able to build its development reasources faster than the FSF could build the infrastructure to deal with them. The fact is that when all was said and done, the splintering was healed, and the FSF has endorsed the steering committee that Cygnus helped to create, and now both Cygnus and the FSF are working on a common version of GCC. How many other open source project have you seen come together once they splintered? *BSD? Ha!

M

Embedded Linux users?

[Bill Henning]

Does anyone have a list of companies using Linux for embedded work? Preferrably large industrial companies?

I design (soft) real-time industrial control software and there are some PHB's at work worshipping the Microsoft CE way...

I'd love some ammunition for getting embedded Linux in the door.

Stupid Q.

[sTeF]

Is it possible to let eCos run on my Handheld instead of WinCE?

Re:Pre-empt Linux Fragmentation?

[Capt Dan]

I think it's been posted here before, but there is a big difference between an honest to goodness news article and a Company Press Release. Which is what the cygnus article is.

Of course the company will put a spin on their press releases. The better they sound, the more product they sell. Simple. But if this action helps out something like embedded Linux in the process, more power to 'em.

You are correct that the stock kernels are missing some stuff. To the best of my knowledge, Linux cannot currently run inside a doorknob. Other embedded system can and do.

And there are also other embedded systems that, for example, run Win95. I worked on one in college.

Re:Not so good

[jtn]

Wow.. it's mildly entertaining to see somebody so highly regarded be so uninformed. The various BSD-based operating systems have no need to "unsplinter" because the all have different goals to achieve. I'm sure if EGCS and GCC had seperate goals that they would still be seperate entities. Get you facts straight before you spout uninspiring nonsense, please.

Re:Not so good

[spooky ghost]

GCC is now reunited as 2.95, and this is largely based on the egcs code base. So isn't it the case that the superior compiler won? I think if GCC 2.8 had been better then that's what we'd be using. That's open source evolution. Besides, from what I remember, the same people actively contributed to egcs and gcc.

No matter what it looks like, there isn't a .sig here.

Pre-empt Linux Fragmentation?

[Eric Seppanen]

Hey, I think Cygnus is cool too, but this just doesn't make much sense to me. The title of the press release is "CYGNUS ANNOUNCES EMBEDDED LINUX OFFERING; PRE-EMPTS LINUX FRAGMENTATION", and it's subtitled "New EL/IX API Enables Developers to Extend Linux into Embedded Computing Environments". There are two misleading statements here: first, that Linux is about to fragment and we need Cygnus to save us, and second, that Linux isn't capable of running in an embedded system right now. The first one is just plain stupid; that one's easy. The second one is a little more fuzzy.

It's true that the stock kernels are missing some stuff that some embedded projects need. Maybe you need flash-disk drivers or real-time scheduling. And if Cygnus wants to jump in and provide these services, that's great (just so we all realize they're not the only ones). But a stock Linux kernel works great for a lot of embedded systems.

The real point here seems to be building some kind of a bridge between Cygnus' eCos embedded OS and Linux, so that apps that are a little too heavy for eCos can move to Linux and keep a common API. That's cool, too. But this press release portrays that as the savior of the embedded-linux world, and that's just degrading. It makes me respect Cygnus a little less.

Re:Rob is an idiot

[My_Favorite_Anonymou]

Why can't Rob keep the current version of Slashdot in CVS so people ca....


Shut TF up and contribute to the Squishdot [squishdot.org] project. It's OpenSource [squishdot.org].

Maybe you can make a /. clone better than slashdot. O I forget you can't code, how to I know that.


CY

more at EE Times

[Eric Seppanen]

There is an article [techweb.com] at EE Times about this.

Is this just the POSIX APIs?

[Zach Frey]

Both the business wire article and the e/lix page [cyngus.com] seem to be content-free about what e/lix actually is. Given that the eCos homepage says that they are thinking about implimenting the POSIX APIs, is e/lix simply a POSIX API for eCos?

If so, this is very cool, but not world-shattering. It would bring eCos into closer parity with the major proprietary RTOS's, and should make it easier to have more free (libre) software available for small embedded systems.

In any case, it's nice to see eCos and Cygnus getting good press. I hope they do well with eCos; IMNSHO the embedded-systems market is ripe for a good free OS.

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

Very interesting.

[Capt Dan]

So I just skimmed the eCos whitepaper which can be found linked from the eCos page [cygnus.com] For those of you ho are unfamiliar with how embedded systems are designed/work/react this whitepaper should be informative. From the quick glance I gave it, eCos seems quite nice with the key feature being POSIX compliant. eCos seems to implement a process model where POSIX threads are also available. Thank God. I've been getting tired of this holy war going on between the process based embedded systems camp and the thread based embedded systems camp.

I think that the point that should be made is that while Cygnus will be supporting work for both eCos and embedded Linux, eCos is their baby. Now before someone gets all huffy and ticked off, note that eCos is a real time embedded system, and Opensource. And when it comes to embedded systems, designing real time into the kernel is a major boon as opposed to something like rt-linux where linux is essentially run as a process of a smaller real-time kernel (yes, that is an oversimplification, but basically true).

Quite frankly, I do not see embedded linux being able to run inside a doorknob anytime soon, there's a lot of work still to be done. eCos already has that ability, and according to the whitepaper Linux and gdb can be used as the development platform. The real point is that all the reasons I have heard of for wanting embedded Linux, seem to be embodied in eCos. POSIX compliant, open source, real time embedded system.

Ahem. Go Cygnus, go Cygnus, go Cygnus, go. (Insert cheerleaders and dance routine here)

Now all we need is support for broadband multimedia to take the settop box market away from CE. The fact that CE is pretty much guaranteed to have directx and realaudio/video is a *major* selling point.

And if you don't like what I had to say about embedded Linux, you know what you can do? Go code it. Get its development going that much faster.

Re:Very interesting.

[shambler snack]

*laughing out loud*
This reminds me of what Java/Sun went through to get Java back into embedded systems. Original Java was way to big to fit in the proverbial doornob (or JavaRing, in their case), so they backed up and gave us several leaner versions targeted for small machines.

As far as DirectX and RealAudio/Video, what open standards-based technology exists that has equivalent serious capabilities of those two that could be incorporated into eCos and/or Linux?

I've glanced at eCos but never had the time to give it much review. Think I'll dig a little deeper. Thanks for the insites.

Yes MMU, No Process Model

[Real Timer]

Most RTOSs today do indeed take advantage of the MMU. For example, the MMU is used to control whether a given page of memory is copy-back cached, write through cached, or non-cached. As well, some RTOSs distinguish between supervisory and user mode, and use the MMU to control access to kernel data structures from user code.

What they don't have (as a rule) is a process model. Everything runs as a bunch of kernel tasks, or as a bunch of threads in one big user process. At the high end, there are RTOSs (e.g. LynxOS and embedded Linux) which have a full process model, but allow memory locking and preemptive scheduling.

Working in the embedded space takes a different mind set. Linux can definately be used in some cases, but its resource heavy compared to any RTOS I've looked at. Even LynxOS is highly configurable in terms of allowing you to pare the kernel down to a bare minimum. Of course, with Linux source code, anything's possible...

Rob is *no* idiot

[Mads-Martin]

If Rob Malda feels that ./ is not yet mature enough for OS - then it's 100% ok.
If Rob Malda never want's to make ./ OS because he want's money for it - then it's 100% ok.
If Rob Malda's coding abilities sucks and he is ashamed of them - then it's 200% ok

Why is it so hard for the Open Source community to accept that not everyone want to release their products as OS? If people want to go OS, then it's a great thing, but if people don't, then we should accept it and let them be commercial or whatever their desire is!!

RTEMS *is* GPLd

[Real Timer]

To quote their license: "RTEMS is free software; you can redistribute it and/or modify it under terms of the GNU General Public License as published by the Free Software Foundation; either version 2, or (at your option) any later version." Later in the license, they go on to say: "As a special exception, including RTEMS header files in a file, instantiating RTEMS generics or templates, or linking other files with RTEMS objects to produce an executable application, does not by itself cause the resulting executable application to be covered by the GNU General Public License. This exception does not however invalidate any other reasons why the executable file might be covered by the GNU Public License."

I'm assuming the reasoning is that you can then use RTEMS with GPLd code (Linux drivers, for example). The problem is, this may be legally questionable. I'm not a lawyer, but I would talk to one before embedding any GPLd code in a proprietary product, even with this "special exemption". Why didn't they allow the option of using the LGPL or the GPL? This would seem to achieve the same goal.

Ecos/Linux embedded not suitable - GPL sealed fate

[AaronW]

I researched replacing our current product with VxWorks to use either Linux or eCos. Neither would be an effective solution. eCos is far too limiting. The last I checked it didn't even have TCP/IP support, nor support the Mips processor (which is extremely popular for embedded environments [eCos does have an eval version for the NEC VR4300]). Another problem with Linux is the GNU public license. In an embedded environment it is often necessary to hack the kernel or pieces of it to do what you need.

I found RTEMS http://www.rtems.com [rtems.com] is an excellent solution. It is open source and has the latest BSD TCP/IP stack. The license also allows us to hack up parts of the kernel without having to release the source code back.

For our current product, any RTOS we use we need to make some custom changes to the TCP/IP stack (which involve changes that would NOT be of benefit to the open source community unless the company wanted to compete with us). The eCos license would let us do this, Linux does not.

Don't get me wrong. I support open source and feel that any changes that enhance a product, fix a bug, or whatever that are not proprietary to one specific application certainly deserve to be released back to the community.

Another problem with the Linux kernel is that it is far too bloated. It would take a lot of work to bring it down to size. For example, everything we have is in flash. There is no file system. Our current image, symbols and all, is around 1.25MB compressed (using Zlib, which incidently is much faster than Gzip). We have a lot of code and not a lot of room. Having a small kernel is often necessary. We don't need a file system, virtual memory, security, loadable modules, or many of the other features of the Linux kernel. In fact, due to the fact that everything must be physically linked to the kernel, this totally rules out Linux. The 1.25MB is EVERYTHING, all of our code, protocol snooping, debugger, routing, console, SNMP, and firmware for supporting a second CPU (which runs our custom RTOS which is only a few pages of code).

eCos and RTEMS fill the void nicely in that one can pick and choose which features get compiled in. Unfortunately eCos is missing some very important pieces (i.e. TCP/IP).

VxWorks is a pain in the *ss since it has numerous bugs (i.e. improper cache operation on the NEC VR4300 CPU) and has terrible support (after paying thousands of dollars a year it's not unusual to have to wait weeks or months for a response). Not only that, but we had to buy their networking source code which costs many thousands of dollars (it's mostly just the BSD 4.3 TCP/IP stack, nothing special, and various daemons).

I am seriously looking at moving to RTems in the future. They have always responded promptly and have the features we need. My boss was all for Linux until I told him about what was involved to use it, and the GPL immediately killed it.

If we do move to RTems, I would certainly make a number of the changes we would make available back to the source code, but there are a number of others that we cannot release (since there's competition).

Re:Very interesting.

[bgarcia]

Quite frankly, I do not see embedded linux being able to run inside a doorknob anytime soon, there's a lot of work still to be done. eCos already has that ability,

Cool! Where can I buy one of these doorknobs?


99 little bugs in the code, 99 bugs in the code,
fix one bug, compile it again...

The major problem with running anything on Hand...

[mattz]

...helds is getting a bootloader. There is some substantial progress towards a bootloader for a linux implementation on the MIPS wince handhelds--it's at linuxce.org [linuxce.org]

Re:Pre-empt Linux Fragmentation?

[Real Timer]

"that Linux is about to fragment and we need Cygnus to save us ... is just plain stupid"

They did say *embedded* Linux. And they're right. There are RT-Linux, KURT, Embedix, Lineo and Hard Hat, to name a few. Linux proper has Linus and Ulrich (maintainer of glibc 2.x and a Cygnus employee) keeping the API unified, but this is not the case in embedded Linux land.

"Maybe you need flash-disk drivers or real-time scheduling."

Actually, Linux has had real-time scheduling since 2.0, at least. And there are flash-disk drivers too, at least on the PowerPC.

"this press release portrays that as the savior of the embedded-linux world, and that's just degrading."

A bit spin-doctored, all right, but you can't blame them. Their just trying to hitch eCos to the Linux band-wagon. They've put a ton of effort into EGCS and glibc, so I guess they deserve a break :)