Whacking Droid (Paul McKenney)

  • Video: http://linuxconfau.blip.tv/file/4728179/

  • Paul wasn't directly interested in Android or suspend blockers
    • Then came Linaro..
  • Small thing, so much trouble
  • Parable of the elephant and penguin
    • Message is that external requirements are hard to elicit
    • Much discussion ensues
      • And sometimes consensus is reached
  • For Android, seems like we're stuck in the discussion phase
  • On Flamewars
    • Short flamewars are hard; need to learn fast
    • The longer the flamewar, the more help they need
      • Might not be appreciated, requires thick skin
  • Goals
    • If your goal is to have fun, you're just another flamer
    • Learning, understanding, presenting a neutral view, advocating one
    • Or proposing a comprehensive solution
  • Homework suggestions (to support flamewar analysis)
    • Textbooks
    • Datasheets and technical websites; flamewars often miss facts
    • Reading flamewar itself; avoiding taking sides is tough
  • Comparing RCU implementation energy-wise between server and mobile
    • Energy budget is scary tight on a mobile device
  • Analysis of multiple flames and introspecting hidden assumptions
  • Lessons learned

Changing the X server development process (Keith P.)

  • Video: http://linuxconfau.blip.tv/file/4727626/

  • #1 Old model
    • Everyone committed to master
    • At some point, freeze
    • RM cuts the release branch
    • Only 4 people committed
  • #2 Xorg opened this up
    • Everyone committed to master
    • Release branch ceated
    • Wikipage recorded commit ids targeted to release
    • Release manager cherry-picked into release
    • No testing of actual integrated release branch!
    • From 1.3 to 1.7 releases
  • #3 Only one committer to the release branch
    • Some people publish their own trees
      • Or send patch to xorg-devel
    • All patches need to be reviewed before being merged
    • 1.8 and 1.9 release
    • Why was this change done?
      • Xorg releases were always delayed, sometimes by months
      • Git master often unusable, often unbuildable
      • Very little discussion on even major changes
      • Very limited testing of release branch
    • Reliable release process, better quality code
  • Belief that more developer participation would happen
    • 1.5-1.7 was a very active time in developer process
    • Adam (ajax) removed 500KLOC!
      • CFB, Kdrive
    • That level of actvity
    • Changes per day graph: 1.4-1.7 had tons of commits; maybe 3-4x 1.8/1.9
    • Aggregate changes graph: confirms this, 1.5 and 1.6 removed tons
    • Patches per release graph: review only shows up 1.7 onwards
    • Authors per release: 80-100 is 1.4-1.7, and 1.8 onwards fewer
      • Visualizing by day would be helpful
    • Email threads per release goes up amazingly after 1.7
      • Could be why changes tapered off
  • Xorg has been removing more code than adding since 1.4
  • Peer review; patches being reviewed by different companies
    • Apple patches reviewed by Apple employees
    • Q (Ben H): some kernel patches come with dozens of Signed-Off
      • Keith: we look at Reviewed-By patches
  • Is this a success?
    • Dramatic reduction in development
    • Increase in communication and collaboration
    • Release deadlines met
    • Meets original requirements set by Peter H.
  • Questions about review process, measurements

Booting directly to Linux (Simon Horman)

  • Renesas: SH-Mobile ARM zboot
  • AP4EB and Mackerel
  • Uboot default bootloader
  • Would like to use Linux as bootloader instead of Uboot
    • Uboot reimplements Linux
    • Uboot smaller but flash is now big enough for a kernel
    • Not as well maintained
  • First boot from E-MMC
  • Group within Renesas has upstream-first policy
  • Seems to be OEM focused
  • NOR Flash (non-updatable)
    • Hold ROM
      • MaskRom in NOR flash burnt in factory -- can not be field updated

  • NAND Flash (updatable)
    • Hold U-Boot
  • #1 Boots Linux from NAND Flash
  • #2 Booting from Linux from MMCF (-rc2 patch targeted)
    • MaskRom configured via dip switches

  • #3 SDHI hardware to read SD and MMC/eSD and eMMC
    • Work is 2.6.39-rc1 targeted
    • Not working yet; issue with e-SD versus SD and availability
  • Q: Could other vendors like Google pick this up
    • Code is board-specific and needs to be written per-device
  • Q: how do you pass parameters to the kernel; how do you use a stock kernel
    • Really requires a two-stage bootloader
    • You can compile parameters into the kernel
    • Cited Linaro work on unifying kernel
  • Q: what products is this hardware used within?
    • Vending machines use predecessor of the hardware
    • Size of developer board a bit too big for a mobile device

Linux Graphics Driver Anatomy (David Airlie)

  • Video: http://linuxconfau.blip.tv/file/4720093/

  • Xorg graphics stack is pretty confusing
  • Architecture diagram
    • Diagram from the Ubuntu forum
    • Mesa quite outdated; Mesa drivers moving ahead
      • Mesa very tied to fixed-function; drivers were hard to write
      • Didn't have GLSL compiler
      • Modern Mesa framework has GLSL compiler (Intel)
      • Can support hardware features much better
      • Two driver modules: classic and Gallium
        • nv30/40/50 Fermi
    • Xorg 2D drivers used to be huge
      • Modesetting (70% of Intel driver)
      • Rendering
      • Acceleration
    • Kernel support ended up being seen as necessary
      • HDMI and DVI negotiation (interrupts and training)
      • Suspend and resume
      • 2D drivers got smaller as this stuff moved into the kernel
      • Driver today interfaces X acceleration to hardware interface
      • DRI2 app display setup?
      • Xvideo
    • Intel and Nouveau have dropped modesetting these days
    • David wrote ATI demo tree to drop modesetting
      • Q: modesetting in binary nv and frglx drivers
    • DRI2 interconnects
      • Old DRI had a lock which blocked X completely
      • kernel had special signal blocker; massive hack
      • Clipping was the big problem
        • Backbuffer was shared
        • Needed to be shared between kernel, 2D and 3D bits
      • DRI2 fixed this
        • Moved to per-window buffers
        • Components don't need to know about window clipping
        • Xorg would be informed that a window was to be shown
          • Took care itself of clipping
      • Mentioned context switching between Xorg and driver?
    • Kernel takes Mesa and 2D driver output
      • Ships it to hardware (command stream scheduling)
      • Don't trust userspace; they are send stuff directly to hardware
      • Radeon driver can do lots of bad things
        • Command string needs to be validated
        • Binary drivers probably don't do enough validation
      • Graphics drivers in the kernel have grown 5K to 260KLOC
    • GPU hardware comes next
    • How do we simplify this stuff to increase developer community
      • 3D bits are the easiest to get into
        • Find broken applications and then see if you can fix them
        • Look at shaders and hardware output
      • Modesetting
    • Wayland
      • Very simple model; single wayland compositor process
      • Not sure it's the future
      • If Ubuntu does run Wayland, it's in 5 years, not 2 years
    • GL support
      • GL3.0 going forward
      • Lots of work to be done; 5 year catch-up
      • Patent issue with SGI
        • Could distribute source and build later
    • Embedded GPUs
      • From an OSS space, nothing's happening yet
      • Not sure how long it will take before it happens
    • Multicard
    • Switchable Graphics
      • Multiple cards on them; very weird model
      • Current switcheroo implementation works
    • GPU offloading
    • USB hotplug
      • Plug in USB VGA today and fail, even if before Xorg starts
      • Xorg.conf needs editing
    • Crossfire/SLI for games acceleration
    • Dynerama
      • Hotplugging layer for Xorg
    • Prime
      • Graphics object sharing between graphics drivers
      • Useful for GPU offloading
      • Useful for dynamic switching
    • BSD probably suffers with kernel driver requirements increased

Linux Kernel Development (John Corbet)

  • Video: http://linuxconfau.blip.tv/file/4727307/

  • Largely a success; 4.5 releases a year, 10K changesets/release
  • Talk is about what happens when things go wrong
  • Developer community is intimidating
  • Example: Tux3
    • Daniel Phillips
    • 2008-07-23 announcent, stale since 2009-08-16
    • Andrew: do not fall into the trap of adding features out of tree
    • Daniel admitted he should have merged it
    • LTTng is another example
    • Curious analogy with drafting in cycling
    • Lesson: Merge it early; Btrfs good example
  • Lesson: Contributing code means losing control
    • Example: em28xx, a webcam V4L driver
      • Markus R.
      • 2005-11-08 driver merge, last patch 2009-08-09
    • Example: Hans Reiser blocked ACL feature addition to reiser3
      • Functionality was merged anyway
  • Example: 2.5.x IDE maintenance
    • Martin Dalecki IDE cleanup
    • 2002-02-15 First patch, 2002-08-16 Martin quits, code reverted
    • Martin: "Breakage is the price you pay for advancements"
    • Lesson: Don't break things; listen when complaints happen
  • Example: Con Kolivas scheduler
    • 2007-03-04 first post, 2007-03-19 Linus irritated
    • Ingo posts CFS and gets merged; Con departs 2007-07-25
    • Lesson: If you want to change the kernel, improve it for everybody
      • Or at least don't make it worse
    • Lesson: Some parts of the kernel are hard to change
    • Lesson: Participate in the wider discussion (LKML)
      • -ck list didn't help
    • Lesson: Aim for a solution, not a specific implementation
  • Example: reiser4
    • 2002-10-29 first reiser4 post, 2006-07-20 attempted for 2.6.19
    • Hans arrested 2006-10-11, died since
    • Problems with it
      • Non-POSIX filesystem behaviour
      • Transaction engine
      • Technical difficulties: deadlocks
      • Hard-to-reproduce benchmarks; others couldn't get the results
    • Lesson: Linux isn't a research system
    • Lesson: avoid suggesting people are conspiring against you
  • Example: systemtap
    • 2003-11 Dtrace announced
    • 2005-10 systemtap in RHEL4, 2009-09-22 1.0 released
    • Doesn't think it will ever be merged
    • At 2008 Kernel Summit 50% had tried to use systemtap
      • 20% succeeded!
    • Lesson: Usability for developers
      • If the developers don't see value, it won't get merged
  • Example: TALPA (hooks for virus scanners)
    • Posted in August 2008
    • Nobody liked it; fixing broken security models
    • Requirements weren't well expressed
    • fanotify merged; provides similar functionality
      • Done by the same people!
      • Generalized and fixed notification system in the Kernel
      • Rephrased the requirement clearly
  • Lesson: sell patches to the developers, not management
    • User-space APIs live on, so their design matters
  • Many other examples

Linux Kernel Report (John Corbet)

  • Video: http://blip.tv/file/4730562/

  • Cycle almost exactly 80 days (84, 80, 79, 80, 76) for .33 to .37
  • 2.6.37 11K+ changes, 1200+ developers
  • Stable (Greg KH) on 32 and 36
    • Audience asked for an "LTS" kernel
    • Long-term kernels
      • 2.6.27 Willy Tarreau 2.6.34 Paul Gortmaker 2.6.35 Andi Kleen
  • Btrfs is new default for MeeGo

  • James says that "graphics and wireless" is almost solved!
  • The Embedded Problem
    • Really tight deadlines
    • Short cycles
    • Secrecy
    • Lots of code never makes it into the mainline
      • Android is a great showcase of this problem

Power Management (Matt Garrett)

  • 48-core system is 350W at idle
  • 20W per core when at 100%; on a 48-core system 960W from CPUs alone
  • 5W per stick of DDR at load
  • Getting processors to sleep
  • Even if the memory bus is suspended it is still refreshing at full
    • frequency; you can ask memory to self-refresh however to take you down to 0.1W
  • Discussion mostly about server-scale optimizations

7 Habits of Ineffective PMs (Carol Smith)

  • Video: http://blip.tv/file/4729851/

  • Program Manager at Google, admin for GSoC
    • 11 interviews to get hired for a contracting position
  • Bad Habit: too many status meetings
  • Bad Habit: Don't trust the engineers competence
    • What about slacking?
  • Bad Habit: Keeping checklists
    • You need to know enough about the project
    • If you don't understand the technology that's very hard
    • Need to be able to have an intelligent conversation
  • Bad Habit: Letting management meddle in plan and goals
    • Human nature for management to try and control
    • If the PM maintains authority and managers will mess less
  • Bad Habit: Make everything an emergency
    • Only call it when it's /actually/ an emergency
  • Bad Habit: Don't feel approachable?
    • Need to feel like you're approachable and sensible
      • Carol brings cookies to work
  • Bad Habit: Assume the deadlines engineers give you are accurate
    • Natural tendency of engineer to surprise you
    • Know enough about them to not have to ask
    • PM should pad and underpromise
      • Thank them when they overdeliver
  • Q: Since you can't reward or punish as a PM how do you do it?
    • Create your own carrots (even if you can't give the guy a raise)

Notmuch (Carl Worth)

  • Video: http://linuxconfau.blip.tv/file/4726932/

  • Why email is so painful
    • We get too much of it
    • Some of it really matters
      • Time-critical
      • Valuable
      • Long-lived
  • Email problems
    • Folder-based
    • Scalability limitations
    • Search not a first-class citizen
  • Search can be a fundamental feature
    • Tags are better than folders
    • Email storage can be very efficient
    • Fast, global searching
  • Why not just gmail
    • Some users don't trust the mothership
    • Non-free platform
  • Search as fundamental feature via Xapian
    • Xapian performance is fantastic
  • C lirary and command-line client
  • Emacs UI

libferris (Ben Martin)

  • Video: http://linuxconfau.blip.tv/file/4728924/

  • Website: http://www.libferris.com/

  • 10 years working on this
  • Example fls and fcat into an XML file
  • fls allows specifying extended attributes
  • --ferris-filter for filtering content
  • ferris-redirect takes from stdin into an XML element
  • Also support BDB
  • FUSE wrapper allows mounting a file via ferrisfs
  • You can sort and filter using metadata
    • For instance, order a directory of images by width
    • How does this work when there are non-images?
  • Mount emacs, BDB, RDF, PostgreSQL,
  • atan the result
  • You can rsync tables across PostgreSQL databases mounted
  • Mount firefox, amarok, xwindows, xclipboard
  • Amazing way to script pretty much anything!!
  • How does it introspect the applications?
    • Emacs uses elisp
    • Firefox plugin
    • Amarok via dbus (can mount dbus as a filesystem)
  • Mount gstreamer/gphoto, pull snapshots from streams
    • Requires XML setup
  • fedit command allows editing in $EDITOR
  • Web 2.0 apps: Flickr, google spreadsheets, vimeo, 23hq, youtube,
    • More: twitter, facebook
  • You can get VCards from fcatting flickr contacts
    • How does the authentication work?
      • If you're using HTTP, a special file in .ferris
      • Not putting it in the URL is better
      • Need to set it up first; for Google needs user/pass
        • Count do OAuth later
      • For facebook you can get permanent authentication
  • Indexing and searching
    • ferris-find operates on an index (no trolling filesystem)
    • Xapian, Lucene, Xapian, Google, etc indexes
    • fcreate --create-type=eaindexpostgresql
  • Special support for creating indexes, FTI
  • Emits dbus signals when adding annotation

ChristianReis/LCA2011 (last modified 2011-02-08 04:07:54)