Upside Article On Embedded Linux

Paddy wrote to us about today's Upside article on embedded Linux, and what it can/does mean for Linux. Talks a bit about Lineo, and the possibility of kernel forking - good summary of the landscape.

Comments

Re:Don't care?

[um... Lucas]

Indeed. That's why I love the Mac. It lets me get my work done without worrying about what's happening under the hood... But the MacOS is not meant for the embedded market. At least here, Apple's done something right! :)

Forking is GOOD!

[sjames]

There are a number of valid reasons to fork the kernel. No OS, no matter how good is likely to be the master of everything. The embedded environment is very different from clustered supercomputing is different from workstation.

If you're controlling a VCR, and take a 25% cut in speed to cram your code into the next smaller sized EPROM, you'll be very happy (as long as it's still 'fast enough'). If you are doing clustered supercompution, you'll prefer the speed over the space savings.

For a desktop, you'll probably prefer versatility over a few K of memory and you'll probably be willing to sacrifice maximum speed in order to have a more responsive system (which will actually feel faster on a desktop even though it's slower on batch jobs).

Some of the above are doable with tuning parameters, and by configuring compile-time options. Whenever possable, that is the best thing to do.

The balkanization of Unix was a very different issue. In that case, each proprietary vendor forked the code and closed it. Then they made just enough changes to 'justify' preferring their minor varient over the competition. In truth, most of those 'differences' could have been handled with a few tuning parameters and an ifdef or two in the source.

In short, those were NOT technically justifiable forks, they were business decisions meant to benefit ONLY the corperates who did it.

It is a mistake to lump those two things together.

isn't kernel forking the point of the GPL?

[jemfinch]

Everyone seems so worried about kernel forking, but isn't that the point of GPL? That anyone can look at the code and make what changes they choose to make?

Nothing is intrinsically special about Linux Torvalds. He concentrates on controlling the kernel for the main branch. But if there needs to be a separate branch for embedded systems, cluster systems, and other specialized systems, so be it. I don't want to see Linux become a "jack of all trades, master of none" in the name of not kernel forking.

I say, for it and keep specialized code from cluttering my kernel :-)

Jeremy

Re:isn't kernel forking the point of the GPL?

[Myddrin]

I see your point, but I think there is another reason that we've seen so much FUD about forking the kernel....

The one strong (well in other peoples opinions) arguement against Open source is that there is "no centralized authority" to make the desicion. (Not my arguement, I've seen this numerous times.)

It's like someone born into communism saying "But how does the economy you know how many XXXX's to make?" They would very natually keep harping on this point becuase they can't comprehend supply and demand.

The Closed-Source proponents can't understand that if the fork splits, that it either 1) falls out of use, 2) is kept current with the main source by the forker, 3) becomes a second product (an example might be emacs and xemacs (I know I'm strectching)) or 4) gets rolled back into the main codebase.

What we really need to start working on is to inform people on how descisions are made in the open source community and point out forks that have occured in the past without harm occuring.

At least that's what I think,
RobK

Yup, I like it...

[God I hate mornings]

I like where it's going, I like what it could be in the future, yup, I just like it! Now... if I could just get embedded linux installed into my wife, life would be great!

Unnecessary Forking Is Expensive

[Christopher B. Brown]

Any time you take a code base of (several MB of code) and start a separate edition, this has considerable cost.

The cost is in retrofitting changes that go into one tree into the other tree.

Thus, if there turns out to be a Lineo Fork , the folks at Lineo will find that they either:

• Pay a bunch of programmers to track what's going into the Torvalds Branch and merge that into the Lineo Fork, or
• Risk that useful stuff will go into the Torvalds Branch that either never makes it into Lineo Fork or that has to be independently reimplemented in order to do so.

For instance, if they fork, and ext3 and XFS filesystems are introduced in the Torvalds Branch , it may be as costly (in terms of programmers' time) to introduce those into an independent fork as it was to implement them in the first place.

The folks building embedded systems may not care right now about IP6 or USB or k001 journalled filesystems; if they branch out now, when the support for such things is tentative, it may wind up being difficult-to-impossible to take the code that emerges a year from now and add it in then.

The overall point here is not that Forking is bad and evil and must never happen, Bad! Bad! Bad! The point is rather more like Forking results in there being substantial costs attached to synchronizing the functionality of the varying versions. Forking is EXPENSIVE which can be rather bad.

Linux may be free of charge, but development of code is most definitely not free of cost. And code forks are perhaps the ultimate example of this.

The meaning of "real-time"

[cybaea]

Customers that move from real-time operating systems such as VRTX and QNX to Linux sacrifice a few milliseconds worth of responsiveness, but gain the speed of the open source development community.

The author seems to misunderstand the point of real-time operating systems, which is not to be fast (though, of course, that is always nice), but to have a guaranteed response time.

So in a real-time OS you have pre-emptive scheduling and an upper limit on the time it takes to context switch. This way you can guarantee that an important signal ("this patient is about to die, doctor") is serviced (page the doctor, or whatever) in real-time and in the appropriate time (i.e. before the patient dies.)

Do the current Linux kernel have this feature? There is no reason why it couldn't have: good ol' VMS had basic real-time features built in (pre-emptive scheduling), you could add the rest (I think the product was called ELN and was described as "the best kept secret in DEC"), and you could still use it as a "normal" operating system.

Re:The meaning of "real-time"

[Christopher B. Brown]

There is an RT-Linux "extension" that allows functions that require RT capabilities to be run at higher priority than the Linux kernel itself. That of course means that the critical functions cannot depend on the parts of the application running on Linux; you split your application into:

• Services that require RT service levels, and thus run at a higher level than any Linux code.
• Services that do not require RT guarantees that may thus run as Linux processes.

It's probably fair to say that things like eCos, RTEMS, VX-Works, and QNX should not worry too much about Linux; if the application involves life-and-death control issues, I'd rather prefer to use one of those. In critical cases, the maker of an embedded system will have source code access, whatever the cost.

But there is certainly room for Linux to crowd out lower grade things like WinCE in less critical "Soft RT" applications where the cost of the solution is a critical factor.

My two cents

[um... Lucas]

I don't think that embedded Linux stands to do much in terms of affecting the perception of Linux. I for one, don't care what OS my car uses, my Microwave uses, or my VCR uses. If i need to know or care, then obviously it wasn't implented correctly.

So far as the kernel forking. Who cares? If the kernel forks in order to make concessions to the embedded market, it's still GPL'ed, so other developers won't be left out in the cold. It'd actually be better if it forked in this way, rather than following mMicrosofts footsteps with Win32, where we've now got WinCE, Win9x, and WinNT, which are largely incompatible with each other, serve completely different markets, yet have the same interface and API's tying them together...

With all that, it'd definetly be a boon for developers of embedded devices, supposing the could cut away enough fat from the kernely to make it competitive with other embedded OS'es. Though the cost savings probably won't be enough to make it back to the customer, i'm sure they'ed appreciate having an open platform to develope on, rather than needing to learn the semanics of a new OS when they switch projects...

Compare to the US constitution

[tilly]

Part of the vision of the Founding Fathers is that the people should be free to overthrow the government - by force if need be. They were quite convinced of the benefits of doing this, having just done it themselves.

However the fact that much of the constitution (and some early amendments) has clauses supportive of rebellion doesn't mean that anyone wants to really see one.

It is the same principle. The ability to fork is good. Using that ability is bad and only justified if it not forking is going to be worse...

Cheers,
Ben

modularity is the answer

[jilles]

Forking is a symptom that Linux is reaching a stage where its own weight prevents it from moving further. Basically there are two thing that can happen:
- a fork, from then there are two incompatible versions of linux that will grow further apart in the future since they are maintained by people with different interests
- no fork, this means accepting that linux is unfeasible in certain domains

Probably a fork will happen. Why? because linux is not flexible enough to efficiently provide a solution for both domains (without forking). A few years ago the linux kernel was a big fat monolith with everything compiled into it. The situation has improved over the years but not enough. It's still a monolithical system. An even more modular system would perhaps have prevented a fork since the embedded version of linux could then choose to leave out a few modules or choose to provide custom implementations of a few modules.

The point is...

[Telcontar]

'People like Linux, because they can basically have the same environment for both embedded applications and development. You don't want to cut it down too much or you lose that advantage," Torvalds says.'

Having helped to build such a distribution, all I can say this is exactly the point. Developers can run his program on exactly the same platform that will be used for the product. The only difference is that the product does not have development tools (such as gcc) on it.

This eliminates the need for cross-compiling and uploading the code to the embedded board, making life a lot easier. Also, developers can use a standardized platform they are familiar with.