Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Linux Software

Requirements for Embedded Linux 79

Posted by michael from the no-eye-candy dept.
An anonymous reader sent in: "As Embedded Linux becomes established as a solid alternative to many proprietary OSes and RTOSes, demands on embedded Linux developers and providers are increasing. This detailed technical article by Nicholas McGuire sketches the top requirements for Embedded Linux systems including considerations of user interface, network capabilities, security issues, resource optimization, performance requirements and issues, and compatibility and standards issues."
This discussion has been archived. No new comments can be posted.

Requirements for Embedded Linux More

Requirements for Embedded Linux

Comments Filter:

  • One disadvantage of Embedded Linux -- Hackability? (Score:3, Insightful)

    by philbo ( 204740 ) on Saturday March 09, 2002 @06:51PM (#3135902) Homepage
    One thing that I think may detract folks from using Linux as an embedded OS is its hackability. For example, TiVo is now hacked 10 ways from sunday. As long as it's adding hard drives and so on, the TiVo folks have been pretty cool about it, but when the encryption scheme for storing recordings was hacked, that leaves them open to legal problems.

    While proprietary EOS's are more difficult (for many of the reasons outlined in the article), they can be much more secure (in the weak sense of security through obscurity) than Linux.

  • Embedded Linux (Score:2, Interesting)

    by BrianGa ( 536442 )
    Lots of info on Embedded Linux at the Embedded Linux Consortium [embedded-linux.org]

  • An important concern they left out (Score:4, Interesting)

    by Anonymous Coward on Saturday March 09, 2002 @06:53PM (#3135914)
    And that concern can make or break the deal (and potentially make or break the company): Licensing.

    I used to work closely with a development team that made the transition from a proprietary (and, may I add, unmaintainable and unreliable) embedded OS to Linux. Though some of the concerns in the article did come up, especially speed and size issues, those didn't hurt us much. After all, we could afford a better processor and more memory with the money we saved on royalties and maintenance expenses - these were substantial.

    Unfortunately, if the many features of Linux and the transition from assembler to C didn't hurt us, the licensing did. Things went very smoothly until we needed to make some big changes to the kernel to accomodate a newer version of our hardware. At that point, there was a schism in the group: some of the developers wanted to change the kernel and release the product without source (the "who would find out?" crowd) and the rest of us knew that Linux was not going to fit our needs anymore unless we wanted to give our work away to competitors.

    Well, the "who would find out?" crowd won the first round, and because of release deadlines we "slipped" the kernel changes into the next version of the product. And nobody knew. Except one of us told the legal department about what happened and they became very agitated.

    Now our software runs on embedded NetBSD. It wasn't quite as robust as embedded Linux but it works well and we really can't complain. Transitioning to a new OS took a lot of effort but it was a necessary evil. After all, we couldn't risk getting sued out of existence to save a little money.

    But the question I draw from this is: why not relax the GPL restrictions a bit for embedded applications? It seems like this area of the market will never be dominated by Linux until companies can stop fretting about licensing problems and start concentrating on coding instead.

    -Name withheld so I don't get canned

    • Is your company primarily a hardware company or a software company?

      If it is a hardware company, why should you be concerned that more software or a different OS would be ported to your hardware? More software or another OS could only mean more users.

      • When it comes to embedded systems, most companies dont easily fall into hardware or software, they produce solutions that unify hw and sw. Since most hardware can easily and legally be reverse-engineered and produced in some third world country, the only thing makers of embedded systems have standing between being successful and dying from inability to compete in a commodity market is their software.

        It's really very similar to Apple's market position.

      • Re:An important concern they left out (Score:1, Funny)

        by Anonymous Coward
        Yeah. People who design a technical instrument or a POS system are just thrilled by the notion that some hacker can slip in a different OS. That cash drawer interface code is really cool, and as soon as it's in the kernel source tree people will be able to make boot floppies with an 'eject' command and have loads of fun hacking.
    • Because the whole point of the GPL is in order to allow people to share software development instead of keeping it proprietary and secret. A GPL relaxation? In your dreams.

    • But the question I draw from this is: why not relax the GPL restrictions a bit for embedded applications?

      To which, I'm afraid, the only reply is: "Why not go write your own closed kernel - or actually pay money for one someone else has already written ?"

      The whole point of the GPL is that, in return for the millions of lines of code you receive, you are expected to return the few hundred/thousand you produce. If you don't want to share, no-one is making you.

    • This stupid rant comes up every time
      someone mentions embedded linux.

      http://slashdot.org/article.pl?sid=01/12/18/1924 20 1
      http://slashdot.org/article.pl?sid=01/12/05/172 424 3&mode=thread

      Please look at these two postings and
      you will find this exact same response...
      word for word.



    • Did your dev team look into using Windows CE.NET [microsoft.com] or Windows XP Embedded [microsoft.com]?
    • The restrictions of the GPL for embedded linux _can't_ be relaxed,
      everyone who's ever submitted patches to the linux kernel
      which were licenced under the GPL (almost all) would have to give permission
      , not even linus himself could make that decision. Why not just make any changes you
      need localized to a seperate kernel module? You could then have just the module under a proprietary
      license and keep the rest of linux open, and not break a single copyright law.
    • This is common issue in the embedded world and sometimes is the main reason linux isn't used. I have been in a situation where linux was considered and one of the reasons it lost out was that we felt the amount of real intellectual property we could put into it was limited. We make our systems from parts that other vendors could also buy and so our software really makes a big difference. In these cases, we felt that we had to use either a BSD based system or a proprietary one that allowed us rights to change the full source. We are currently with the proprietary model but the licensing charges are keeping us looking BSD again.
    • You've hit the nail on the head for some embedded applications. We must draw a distinction between embedded systems which are tooled for a single purpose (routers, switches, storage appliances, caching appliances, accelerators, firewalls, etc), and systems which rely more on an application and service layer (PDA's, game consoles, cell phones, etc). Clearly both are technically suited for Linux, but it is unlikely that the first catagory will ever be dominated by linux given the licensing. This is especially true for the high end. Few will build a $100,000 box with GPL'd kernel modifications. The risks in building hardware are too high as it is, (because its so damn expensive todo!).
  • There is quite a bit of info at http://more.sbc.co.jp/slj/docandtool.asp

    It's mostly about the dev. version of zaurus, but I think it applies to others. enjoy

    "Take revenge, shit on a bird"
    -bumper sticker

  • Read this! (Score:2, Informative)

    by Anonymous Coward
    Its a really good read! [microsoft.com]
    • That's quite funny, actually
    • You would have to be really, _REALLY_ stupid to consider embedded windows.
      It has lots of disadvantages and no advatanges of any merit.

      Where you trying to be funny ?
    • From MS:

      Windows XP Embedded is the most reliable version of Windows ever.

      So, tell me - where's Windows on Netcraft's uptime chart? http://uptime.netcraft.com/up/today/top.avg.html [netcraft.com]

      Oh, that's right - WINDOWS ISEN'T EVEN ON THE LIST

      • I hate to say this, but that Windows isn't on the list doesn't mean quite that much. From the FAQ [netcraft.com] about uptimes there:

        Operating systems that do not provide uptime information include;
        <snip>
        * NT3/Windows 95
        * NT4/Windows 98

        The only Windows for which netcraft can track uptime is Windows 2000. Now if only windows 2000 had already existed for long enough to be able to appear in the list...

        Oh well... Go linux! ;) Er.. no, wait... can't say that either... Uhm, *hesitates* go BSD? *winces* ;)
        • operating systems not including uptime?
          whats this $ticks command in mIRC that all the script kiddys use?
          and the ticks api?
          I'm confused, really confused.

          Is it possible for you to clear this up for me?
          I've read the faq and it seams it's netcrafts problem.
          • > I've read the faq and it seams it's netcrafts problem.

            Well, to some degree. Netcraft doesn't have the code to automatically crack the webserver and execute "uptime" or something equivalent on the remote host. Shame on them!

            Instead Netcraft uses a method that analyses the IP packets send back - but that only works for the few OSes with TCP/IP stacks which provide enough information that can be used to calculate the systems uptime - e.g. for those stacks which use a function of the uptime to generate the initial TCP sequence number.
      • well.... neither is linux...
        • neither is linux...

          According to the netcraft FAQ:

          Additionally HP-UX, Linux, Solaris and recent releases of FreeBSD cycle back to zero after 497 days, exactly as if the machine had been rebooted at that precise point. Thus it is not possible to see a HP-UX, Linux or Solaris system with an uptime measurement above 497 days.
  • I'm working on a project and I would need to make a Linux distro that loads up a simple, locked, X screen with a custom made web browser. How would this be most easily done? This is in many ways like an embedded Linux environment...

    • Re:Advice (Score:2, Informative)

      by clasher ( 2351 )
      I would take a look at using uClibc [uclibc.org] a C library for embedded Linux systems. (they are currently working on pthread support in the cvs which is supposedly what is keeping it from being used to compile mozilla/galeon)
      BusyBox [busybox.net] for basic embedded versions of common linux apps (e.g. init, cp, sed, etc.)
      KDrive [jussieu.fr] a tiny X server from XFree86
      Galeon [sourceforge.net] for a fairly small browser (there are some other smaller ones in development (for example Skipstone [muhri.net] and Dillo [sourceforge.net])

      What I would do is compile a stripped down kernel, use busybox for most system apps, and have your init scripts call the tinyX server and then instead of using a window manager have the startx script start galeon in full screen mode using tabs instead of separate windows for popups. The only difficult part may be getting mozilla or galeon compiled because of the gtk requirements) You could try the Xlib mozilla port perhaps.

      For a little bit of info on how I have done a similar project take a look at my linux on a floppy [umd.edu] page.

    • You mean you want to build a linux-based kiosk [linuxdoc.org]?
  • Here is where the beauty of us Electrical/Computer engineers come out. When you get into funky/new hardware, you need us guys.

    What I propose that there should be a standardized set of low-level functions, with charts telling which platforms take how many cycles for each function. In this way, with just one layer, you could make truly portable code. Like a . In this way, the EEs could figure out how to make a set of hardware conform to a universal interface.

    For instance, Motorola and Intel have two different Opcodes to ASCII Adjusted Addition. Motorola has AAA, Intel has something else (I forget right now). If you could make something at the very end change it, you could have code go from one device to another without much of a tweak. I realize that that is sorta the role of a compiler, but it needs to be ramped up. Linux on ANY device. Then we could focus on making it perdy.

    Just my $.02.

    Joe
  • Step one, configure and install the Linux kernel. Step two, configure and install uClibc [uclibc.org], step three configure and install BusyBox [busybox.net]. Step four, setup the bootloader (depends on architecture). Step five, reboot into a working system...
    • Yeah, right.

      I've just completed a 3 month development contract for an automotive company using embedded linux, and NO WAY is it that simple. Embedded Linux has a long way to go before it can compete with other systems, most notably in the areas of configuration management (the kernel configuration process for embedded targets is particularly poor) and device drivers (Linux in the embedded world badly needs a Hardware Abstraction Layer). On some popular embedded platforms (think Motorola, and telecoms), it took a major kernel revision (2.2 to 2.4) to fix problems with the UART driver.

      The fact that the two most successful embedded architectures have forked their own kernels suggests that Embedded Linux is still quite badly fragmented, and no-one designing a system from scratch wants to see that.

      Jon.

  • Can i trust slashdot for good quality MS bashing now? I dont know ...
  • I'm looking to build a small embedded application (basicly a remote control car), I sure know there are better things to use, however I want to be able to use the parts for other projects.

    Where would the best place to look for such devices?

  • Sorry, it hasn't happened yet (Score:3, Interesting)

    by owlmeat ( 197799 ) on Saturday March 09, 2002 @08:34PM (#3136278)
    "As Embedded Linux becomes established as a solid alternative to many proprietary OSes and RTOSes"

    If anything,the embedded Linux hysteria has died down quite a bit. Linux has it's share of problems in the embedded marketplace. Large memory footprint, filesystems that need time to shutdown, interrupt latency to name a few. I work in the single board computer industry and we've seen a sharp decline in the requests for embedded linux support over the last year.

  • Embedded vs. "desktop" perspectives (Score:5, Informative)

    by apk ( 120253 ) on Saturday March 09, 2002 @09:04PM (#3136351)
    First off, it's an excellent article covering most of the issues that arise in embedded systems -- you should at least peruse it if you're going to comment in this thread. One of the biggest issues for non-embedded developers to understand is that each development task is somewhat unique -- different hardware, I/O requirements, cost targets, time to market, etc. It's not a [relatively] standard environment like that of a typical desktop computer. In fact, the vast majority of embedded devices are "headless" -- no keyboard or monitor, so support for video drivers and/or X only impacts a very small number of applications.

    My company recently went down the path of evaluating several embedded linux suppliers, including Hard Hat Linux [hardhatlinux.com], LynuxWorks [lynuxworks.com], RTLinux [fsmlabs.com], and others. This evaluation was for an embedded communications platform.

    There are many "real-world" issues that will arise when considering Linux instead of some of the more established embedded OS players (WindRiver/pSOS [windriver.com], Green Hills [ghs.com], Keil [keil.com], QNX [qnx.com], et al -- see Embedded Systems Programming magazine [embedded.com] for a pdf summary of embedded OS providers [cmpnet.com]). These real-world issues, which will vary in importance among organizations for various reasons, include:

    • Existing non-linux OS usage (e.g., WindRiver)
    • Staff familiarity with Unix-like programming (most embedded developers know traditional RTOS-like architectures, not unix IPC methods or socket programming)
    • Ease/difficulty with which already-written application software can migrate to a new OS
    • OS support for preferred hardware devices (processor, communications peripherals, flash, etc. -- writing drivers from scratch isn't desirable)
    • Internal corporate or organizational resistance to change (don't underestimate this one, folks!)
    • Product life cycle phase
    • Existing customer experience(s) with any previous OS-related behavior that may change under linux (customers like seeing behaviors they've seen before, not something new)
    • Hard real-time versus soft real-time requirement(s)
    • Communications stack and protocol requirements

    In short, development in the embedded world tends to have many more complications associated with it. That's not necessarily bad -- in fact it often makes it more technically challenging and thus professionally satisfying -- it's just something that ought to be recognized, acknowledged, and taken into account when OS decisions are being made.


    Andy

  • I guess the distinctions between embedded and non-embedded systems are disappearing.

    Traditionally, embedded systems have a minimal user interface (number pad and 7-segment displays come to mind), minimal ROM and RAM, no mass storage, and hard real-time requirements. For a system like this, Linux (or any desktop, mini, or mainframe OS) seems both inadequate and bloated.

    Today's definition of an embedded system seems to be "a portable general purpose computer system". Perhaps we should just call it that rather than use the term embedded system.
    • Traditionally, embedded systems have a minimal user interface (number pad and 7-segment displays come to mind), minimal ROM and RAM, no mass storage, and hard real-time requirements. For a system like this, Linux (or any desktop, mini, or mainframe OS) seems both inadequate and bloated.

      When I see inquiries about using Java in the comp.arch.embedded newsgroup I cringe*. It would seem that there needs to be some distinction made between traditional embedded systems and this new class of device that shares some characteristics with "PC's".

      *not affiliated with Bob Cringely or the Columbia Broadcasting System.

  • Embedded Linux Presentations (Score:4, Informative)

    by Bill Kendrick ( 19287 ) <bill@newbreedsoftware.com> on Saturday March 09, 2002 @11:06PM (#3136616) Homepage
    The last two Linux Users' Group of Davis [lugod.org] meetings have dealt with embedded Linux.

    At our last meeting [lugod.org], a couple of cool folks from BlueMug [bluemug.com] in Berkeley came and talked about an embedded Linux prototype they built for a client (photos [lugod.org]). Their presentation slide is also online here [lugod.org] (2MB PDF).

    At the meeting before that [lugod.org], Rob Wehrli of Arizona Cooperative Power [azpower.com] came to talk about Clinux (photos) [lugod.org]. His presentation is online [azpower.com], too.

    Enjoy!

Slashdot Top Deals

Real Users know your home telephone number.

Close