Linux.conf.au 2014 – Day 5 – Session 1

D-Bus in the kernel by Lennart Poettering

  • kdbus
  • Most newer OS designs started around powerful IPC
  • Linux only had IPC primitives ( sockets, fifos, shared memory)
  • DBUS is powerful IPC
    • Method Call Transactions, Signals, Properties, OO, Broadcasting, Discovery, Introspection, Policy, etc,  etc etc
  • D-Bus has it limitations
    • Suitable only for control, not payload
    • It’s inefficient ( 10 copies, 4 complete validations, 4 context switches per duplex method call transaction)
      • Can we optimise that rather than moving it into the kernel? – “We are, We are moving it into the kernel with kdbus”
    • Credentials one can send/recv are limited
    • No implicit timestamping
    • Not available in early boot, initrd, late boot
    • Hookup for security frameworks happens in userspace
    • Activatable bus services are independent from other system services
    • Codebase is a bit too baroque, XML
    • No race-free exit-on-idle bus activated services
  • D-Bus is fantastic, solves real problems
    • Right approach: good concepts, generic, comprehensive, covers all areas
    • Established, it is the single most used local high-level IPC system on linux, bindings most languages
    • Used in init systems, desktop, etc
  • kdbus
    • Suitable for large data (GiB), zero-copy, optionally reusable
    • Efficient ( 2 or fewer copies, 2 validations, 2 context switches, per duplex method call transaction)
    • Comprehensive credentials sent along ( uid, pid, gid, selinux, cgroup, caps, audit, etc etc)
    • Implicit timestamping
    • Always available from earliest boot to latest shutdown
    • Open for LSMs to hook into from the kernel side
    • Activation is identical to activation of other services
    • Userspace is much simpler, No XML
    • Rece-free exist-on-idle
  • Overview
    • Intention to replace current D-BUS implimentation
    • Should be drop-in so program using bindings should be drop in without changing anything
    • No performance tests yet
    • Receiver buffers
    • Single copy to destinations(s)
    • method call Windows
    • Name registry
    • memfds
      • File descriptors for memory regions
      • Zero Copy
      • Sealing
      • At 512k and above zero copy is faster than single copy, below that the mapping overhead is too expensive
      • a bit like Android ashmem
    • Signal Broadcasting
      • Bloom filters
    • Userspace
      • proxy provides compatibility with dbus1 sockets
    • When?
      • Code all there, pretty much implemented, policy still to do
      • Compile-time switch in systemd
      • We hope to get in the kernel in 2014
      • gdbus support coming soon

 

VisualEditor: Wikipedia’s new editing system, and how you can use it too by James Forrester

  • Why a visual editor
    • Drop off in new contributors is major issue for wikipedia
    • MediaWiki is based on the very rich wikitext syntax
    • Wikitext stops people becoming contributors or staying away
    • Not an appropriate way to ask people to contributive things in the 21st century
    • Prevents us from providing other helpful editing tools
  • Flexibility and modularity
    • Modular
    • support by 300 languages
    • replace or extend existing tools
    • expand it for editing new content
  • What?
    • Client-side JavaScript contentEditable HTML editor
    • Stand-alone, integrate into any platform
    • Mediawiki integration (parsoid converts HTML+RDFa to/from wikitext)
  • 3 Main layers
    • Data Model
      • We can’t edit the input HTML+RDFa directly
      • Reliable convert from HTML to things we can edit and back without corruption
      • Synchronise with ContentEditable (both ways)
      • Needs to allow real-time collaborative editing
      • All sorts of problems with spliting characters in various languages
    • Browser contentEditable
      • Messes up HTML, inconsistent key handling
      • Native text insertion, spell-check, selection and cursor
      • Equal rendering
    • Programmatic cursor handling
      • Intercept the browser’s native cursor handling
      • allows us to skip over non-editable elements
      • Thought this will allow to avoid UX issues
      • but this breaks internationalisation
      • Move to “observe and fixup” of native browser action
    • Input Method Editors
      • Lots of languages reply on IMEs
      • Mainly East Asian and Indic languages
      • Each IME has it’s own unique way of changing content
      • But can change by OS, browser, IME version
    • SurfaceObserver
      • Poll DOM for changes and notify model
      • Lots of events emit no of few events (eg spellcheck)
      • Possibly use MutationObserver in the future
      • Re-render if really necessary
    • Actual rich editing of stuff
      • Annotation (bold, underline)
      • Generated content (references, tables )
      • Tool UX types – Dialogs
  • Future
    • Patches welcome
    • Maybe can be integrated in wordpress or something ( but might be hard)

 

 

Share