Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Linux Software

Upside Article On Embedded Linux 42

Posted by Hemos from the going-to-the-little-place dept.
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.
This discussion has been archived. No new comments can be posted.

Upside Article On Embedded Linux More

Upside Article On Embedded Linux

Comments Filter:
  • Some things to remember about the embedded market:

    1) The present 8 bit processors work fine for many tasks. So why have all the bits needed for an OS when an 8051 or z80 will do the job.
    2) The embedded market lives and dies (at least as far as management is concerned) by IP (Intellectual Property, not Internet protocol

    Given 1 and 2, any of the 'modern' Oses (WINCE, QNX, EPOCH, Embedded NT, *BSD or even Linux) need 32 bits and relying on a GPLed code base opens you legally up to releasing part of your IP to 'the community'.

    Even if you don't HAVE to release your code, do you, as a manufacturer, want to have to go to court to prove you don't have to a jury of your peers, is someone demands the code?

    Most companies that have IP they want to defend don't want to take that risk, even if the cost of GPL is $0 per seat, and WINCE is $35.

    There *IS* a choice to the GPLed Linux in the Open Source OS arena. It's BSD. And, the BSD license *DOES* protect the IP of others.

    If the goal of the Open Source world is to promote Open Source, then why the drum beats for Linux, when, for the embedded world, BSD is a better choice to protect what the embedded world considers its most valuable asset - IP?
  • Now... if I could just get embedded linux installed into my wife, life would be great!

    Remember, an operating system is no more reliable than the hardware on which it runs.
  • Why would you prefer VxWorks over Linux in critical applications? It began life as BSD after all.
  • Yes, but if a group of people fork the Linux kernel, do they have the right to attach the Linux name to their new kernel and gain instant credibility and attention?

    In my opinion, they should change the name a little. But that would be Linus' decision.
  • It seems to me that they are going to put some proprietary glue into their embedded distro.

    From talking with them, it didn't sound like it would be GPL'd.

    Its my understanding (someone from Lineo can chime in here and correct me), that they will
    sell "their" linux with a Royalty fee for each system deployed.

    That is the pre-historic business model currently used by several of the embedded O/S companies.

    The problem with making Linux into an embedded system is that it is a PITA to strip it down to a reasonable size (I know, I am doing it now).



  • For those of you craving a more in-depth analysis of the embedded Linux field, I apologize for leaving so much on the cutting room floor.

    The forking issue came up both because of last week's uproar over TurboCluster and my background reading on RTLinux, an "extension" of the Linux kernel that brings the real time capabilities to the fore.

    Basically, I wanted to see what Linus thought about such "extensions." Apparently, he seems to approve. As a reader mentioned above, the GPL allows forking. This only becomes a Unix-style problem when the bulk of embedded developers -- a more commercially-minded group than PC hackers, apparently -- suddenly decide to branch off and start their own kernel group.

    As for knocking the depth of Upside's content, what can I say? This is an interactive medium. If I get a ton of e-mails today and tomorrow begging me to dig deeper, I won't feel like I'm kicking so many readers out of the sandbox just by using the RTOS acronym.

    Later, Sam Williams Upside Today
  • As other posters have stated, the embedded market is a realtime (or more properly, low latency) market, which Linux does not support well. Fortunately, the drive to finer grained semaphoring to support ever larger SMPs also, quite accidently, goes a long way to making Linux a low latency kernel .. which is exactly what the embedded device world needs.
  • Forking can be good, forking can be bad, but that's not the point.

    If Linus wants to stop his software from forking then he should have placed restrictions upon users to prevent such. However, since he chooses to use the GPL, he chooses to allow forking. Hence, the choice has been left, by Linus, up to the user. So let the user make the choice!

    We can always choose to ignore a user who forks software in a manner we don't like.

  • These guys are all competing these days on the basis of how much they resemble Linux, in the sense of being interoperable at the network level and adhering to standards and conventions internally. So the customer can choose according to how one particular offering happens to meets their needs: A leaner meaner windowing subsystem perhaps, better HDLC drivers, better pricing vs. licensing terms, development environment, whatever.

    The beauty of it is -- and incidentally this points out why we don't need to get worked up about forkin' forks -- when you get all said and done you can telnet/ftp into any one of them. At the other end of the wire they all can pass, to varying extents, what we might call the Penguin test of OSes: If it BOOTPs like a penquin, and if it NFSes like a penquin, it's going to play well with everyone, except possibly certain dain bramaged miscreant DHCP clients out of Redmond.

    sync;sync;sync

  • 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! :)
  • This would also blatantly violate the GPL.
  • Is it me or does it seem like this article is a bad anthology on Linux embedded systems. It sounds as though the author was taking stabs in the dark about what linux really means to this market. Linux is small, Unix the father to linux is based entirely on the premise of forking. This should seem obvious because of the fact that you can run seven apps(20 max) on the same desktop and not get the Windows blue screen of death.

    Embedded systems is the next wave, but definitely deserving of more than a page of text. Just Slashdot alone has several articles pouring in regarding cheap hardware becoming ideal embedded devices(the router/mp3 player, the tiny web server). The market deserves just as much attention as the desktop market because the desktop phenomena is 20 years old and soon to hit the performance peek. Wake up, progress is all about expanding.
  • Remember, an operating system is no more reliable than the hardware on which it runs.

    The hardware is great... it's just the damn internal logic errors in the current os!

  • Where is Embeded BSD. In many ways the GPL is a pain for the embeded market. I if I write a cool Smart Media Divice driver do I have to realse it to the rest of the world? Under GPL I think I do. Under BSD I think I don't. Don't flame me I don't even have BSD I am a Linux user but I can see why an embeded company might not want to live with GPL.

  • 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? (Score:3)

    by jemfinch ( 94833 ) on Thursday November 04, 1999 @08:02AM (#1563669) Homepage
    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
  • 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!
  • Having an open platform to develop on is one thing.

    But developing on the same platform as your target is another. No emulators, no conversions, it's the same thing.

    That is what the developers want. Portability

    Personally, I don't think that anybody would want to go out and have to pay $300 for a copy of Office Pro 2000, and then have to spend another $150 (or something like that) for Office Pro 2000 Windows CE version.

    In this competition, I have to give the advantage to Linux.
  • We already know all this, I would have expected a little more worthy article from Upside (which has been fairly interesting).

    Articles like this one have been posted before... to sum it up:

    • Linux has freely available code -> modified to your embedded system's use.
    • Linux has networking support built in.
    • Linux also is a very generalized kernel, so things have to be whittled away, no problem, see point #1.
    The only thing that was interesting about this article is that they start to mention WinCE and Microsoft, but then never follow up on comparing Linux vs WinCE.
  • 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" (Score:3)

    by cybaea ( 79975 ) <allane@@@cybaea...com> on Thursday November 04, 1999 @08:17AM (#1563674) Homepage Journal
    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.

  • 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...
  • 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
  • uhm, the point of this article is not the forking of the kernel. most of the uses that people will build into the kernel for their embedded use will STAY IN THEIR OWN SYSTEM. they obviously have to distribute the changes to whomever recieves the end result, but there is little to no chance that most of these specialized changes will make it into the stock kernel.

    another example of another irrational (ignorant?) fear.

  • 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
  • (Hey, watch that innuendo...)

    What they would need is someone like Linus in a "master control" position to make sure that all the feature development that's relevant to the forked code gets moved over. It's no good if suddenly you need a feature from 6 months ago in a segment of code that's already mutated 3 more times. You also need someone like Alan Cox that can field cross-project patches into a pipeline for the master control person. The problem you'll run into quickly is two-fold. You dilute the quality of people working on the main thread/fork and you end up with competing personalities/styles between forks. Tread carefully.
  • Doh! I meant that to be in the thread on expense of forking....
    Nergh! What a day.
  • Nothing is intrinsically special about Linux Torvalds
    Well, in the sense that anyone who had his technical abilities could have done the same... but Linus actually did create something something quite remarkable. In that sense, he is intrinsically quite special.
    I don't want to see Linux become ...
    I personal hope Linus continues to make Linux whatever he damn pleases it to be. I am just grateful that he granted others (some) freedom to derive new works (ie: fork) from his remarkable contributions.
  • There is an RT-Linux [nmt.edu] "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, [cygnus.com] RTEMS, [army.mil] 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.

  • The primary war seems to be between Windows 98/NT and Linux, and the secondary war is about Windows CE and embedded Linux... although for some uses the full Linux distributions can also go head to head with CE.

    Actually I am VERY interested in possible embedded uses of Linux; I've spent most of the last ten years designing industrial control software....
  • 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.



    The same could be said of your computer. If you have to know what operating system its running, it wasn't implemented correctly. However, most of us power users out there would like to know. If only I could reprogram my VCR so that I could actually use it.... Then I would patent one click recording of my favorite shows. ;-)

  • PicoBSD is as close as you're going to get right now. http://www.freebsd.org/~abial/picobsd.html [freebsd.org] provides a bit of information on the subject.

    Ikan.

  • 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... (Score:3)

    by Telcontar ( 819 ) on Thursday November 04, 1999 @08:52AM (#1563688) Homepage
    '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.
  • I if I write a cool Smart Media Divice driver do I have to realse it to the rest of the world? Under GPL I think I do

    No. Linux explicitly allows binary closed-source "modules" (ie device drivers).

    If you need to modify the actual kernel source to use your module, you have to release that code. Most likely that code is not going to reveal your Kool Secret Stuff (TM), since it just calls some new module interface. I think you will get some pretty nasty remarks from OSS if you do this and your code will never go into the main source, so try to avoid this.

    PS: This is all my opinion, I don't know for sure.

  • Actually, if you write a driver, you do not have to distribute source under GPL, you just cannot include it in the kernel source. The kernel allows proprietary kernel modules in binary form.

Slashdot Top Deals

He has not acquired a fortune; the fortune has acquired him. -- Bion

Close