Difference between revisions of "Embedded linux status"

From eLinux.org
Jump to: navigation, search
(Graphics: add some notes about recent graphics work)
(Graphics)
Line 169: Line 169:
 
*** OpenGL 2.1 supported now, OpenGL 3.0 support coming soon
 
*** OpenGL 2.1 supported now, OpenGL 3.0 support coming soon
 
**** geometry shaders, tesselation
 
**** geometry shaders, tesselation
 
 
*** architecture:
 
*** architecture:
  

Revision as of 11:07, 17 May 2011

Here is an outline for a presentation on the status of embedded Linux:

This is essentially User:Tim Bird's private collection of interesting notes about the status of embedded Linux. It tends to get updated right before a Linux conference.

NEWS: Tim Bird's Status of Embedded Linux BOF (PDF) (September 2010) presentation from LinuxCon Japan 2010 is now available.

Process for adding information

Anyone can add information to this page. I used to maintain the information at the Technology Watch List, but the table format there is a bit constrictive. (It would be nice if MediaWiki had a table editor!!)

Since I have to form this stuff into a "State of Embedded Linux" presentation several times a year, keeping the information in wiki outline format is convenient for me. It's easier to put directly into a presentation.

Please place information in bullet form, with a link to a supporting article, in the appropriate sub-section below.

Page History

I'll let MediaWiki store historical versions of this page. If you want to see what the hot issues were from a last year or a few years ago, please see look at the page history. (Although, updates of this page have historically been a bit spotty).

Presentation History

Here's my presentation history:

Uncategorized info

This is where I put stuff I haven't had time to analyze or sort into the appropriate category:

May 2011

Quote:

LinuxFR : What is your opinion about Android ? Are you mostly happy they made cellphones very usable or sad because it's really a kernel fork ?

Linus Torvalds : I think forks are good things, they don't make me sad. A lot of Linux development has come out of forks, and it's the only way to keep developers honest - the threat that somebody else can do a better job and satisfy the market better by being different. The whole point of open source to me is really the very real ability to fork (but also the ability for all sides to then merge the forked content back, if it turns out that the fork was doing the right things!)

So I think the android fork forced the mainline developers to seriously look at some of the issues that android had. I think we've solved them in mainline, and I hope (and do think) that android will eventually end up merging to mainline. But it will probably take time and further effort.

I think the more serious long-term issue we have in the kernel is the wild and crazy embedded platform code (and mostly ARM - not because ARM is in any way fundamentally crazier, but because ARM is clearly the most successful embedded platform by far). The embedded world has always tended to eschew standardized platforms: they've been resource constrained etc, so they've done very tailored chip and board solutions, and felt that they couldn't afford a lot of platform abstraction.

That causes a big maintenance headache, because then all those crazy platforms look slightly different to the kernel, and we have all that silly code just to support all those variations of what is really just the same thing deep down, just differently hooked up and with often arbitrary small differences.

But that's something that happens both within and outside of Android, it's in no way android-specific.

LinuxFR : What about the technical differences between Android and mainline ? Do you think the "wakelock" controversy is solvable ?

Linus Torvalds : I think it is technically largely solved (ie "details to be fixed, but nothing fundamentally scary"), but practically once you have an interface and existing code, it just is a fair amount of work to change. And there perhaps isn't quite enough motivation to make those changes very quickly. So it will take time, and probably several releases (both mainline and adroid) to actually happen.

LinuxFR : Can you explain why you're not happy with the ARM patches sent to you during merge windows ? Is there an obvious solution for this fragmentation problem ?

Linus Torvalds : Obvious solution? No. The problem is the wild variety of hardware, and then in many cases the Linux ARM platform code (not the ARM CPU support, but the support for certain chips with all the glue issues around the CPU core) has been mostly ugly "copy-and-paste" from some previous ARM platform support file, with some minimal editing to make it match the new one.

And it just results in this unmaintainable mess. It becomes painful when somebody then fixes some core infrastructure, and you end up with a hundred different ARM files all using that infrastructure. That happened with the IRQ chip driver cleanups Thomas did recently (well, has been doing over along time, the recent part is really just the final removal of some nasty old interfaces).

It results in other maintainability issues too - patches being big just means that people won't look at them as carefully etc etc. So it's just a bad situation. Many of the cases should be solvable by having better generic solutions and then plugging in just some per-platform numbers for those solutions.

April 2011


Other

  • CONFIG_PM being eliminated - improved PM configuration
  • ftrace using -mfentry (feb 9, 2011 lkml, steve rostedt)


April 2010


Previous to April 2010

  • SystemTap 1.0 now includes support for cross-compilation.
  • Patches for dynamic printks
  • writing to /dev/kmsg to generate a printk (not new, but I just discovered it)
  • LZO kernel compression is in 2.6.33
  • Arjan van de Ven's timer-slack code - http://lwn.net/Articles/369361/

Kernel

Kernel Versions

Bootup Time

  • pre-linking
  • XIP
  • (see filesystem work)
  • KFT
  • embedded bootchart

Memory Management

System Size

Security

File Systems

  • YAFFS2
    • Mainline effort by Charles Manning
  • LogFS
    • Joern disappeared again
  • Squashfs
    • Now supports LZMA2 in mainline
    • CELF funding SquashFS on MTD work
  • Arnd Bergmann's work on optimizing Linux FS for cheap flash media
    • See ELC presentation and Linaro page
  • Tim Bird's treadahead work
    • See ABS presentation

Legal Issues (licensing and patents)

Graphics

  • OpenGL ES
  • whither fbdev?
  • 2D - Android doesn't have a native 2D API (or it's changing?)
    • [RESEARCH - did Android drop it's native 2D API? (skia?)]



  • Intel work on graphics in kernel:
    • See Kieth Packard's video from September 2010: [Meego Graphics under the hood: http://www.youtube.com/watch?v=YRYTCQqrFcA] OSCON 2010
    • Working on grphics KMS and DRI in the kernel
      • good for faster booting
      • good for less flicker on transitions
      • higher performance 3d graphics
      • better memory management
        • kernel can pull memory back from graphics processor on low-memory conditions
          • [RESEARCH - status of memory allocation discussions at ELC?]
      • per CRTC pixmaps
        • allows for zero-copy rotations
        • support for larger screens
      • support for multiple screens
      • wayland (non-X-windows)
        • moving away from X on Meego
        • support for multiple APIs
      • EGL
      • OpenGL 2.1 supported now, OpenGL 3.0 support coming soon
        • geometry shaders, tesselation
      • architecture:
user space: Open GL   (compiler for shaders)
             mesa
             i915 driver
-------------------------------
graphics interface (is not opengl, but a device-specific abstraction)
-------------------------------
kernel space: DRI
              i915 driver

kernel space driver is a small driver Combination of DRI and GPU-specific driver is called the Graphics Execution Manager (GEM)


    • Android is using LLVM for compiler shaders
      • Android renderscript
      • ADD - renderscript info
    • ADD: Khronos standards talk?

Audio

Multimedia

  • GStreamer - held first ever GStreamer conference in October (co-located with ELC Europe)
  • Khronos is working on their stuff

Embedded-specific features

infrared remote control support

Middleware

  •  ???

Tools

Tracing

Toolchains

  • Linaro publishing toolchains - one directly for Android use

Distributions

  • OpenEmbedded
  • Embedded Debian
  • PokyLinux
  • Ubuntu Mobile

Distribution tools

Meego

  • Meego - what's up now that Nokia bailed?

Android

Industry organizations or projects

  • LiMo - anything happening?
  • CELF => CEWG under Linux Foundation
    • CELF projects
  • Linux Foundation
    • Lots of stuff going on in embedded:
      • Yocto
      • Meego
      • CE Working Group
  • Linaro - 1 year in
    • see David Rusling's presentation from ELC

Embedded Linux usage

Resources