%include "default.mgp" %default 1 bgrad %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %page %nodefault %back "blue" %center %size 7 Introduction to the Linux Development Model %center %size 4 by Harald Welte hmw-consulting / gpl-violations.org / openmoko.org %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %page The Linux Development Model Introduction Who is speaking to you? an independent Free Software developer, consultant and trainer 14 years experience using/deploying and developing for Linux on server and workstation 10 years professional experience doing Linux system + kernel level development strong focus on network security and embedded expert in Free and Open Source Software (FOSS) copyright and licensing digital board-level hardware design, esp. embedded systems active developer and contributor to many FOSS projects thus, a techie, who will therefore not have fancy animated slides ;) %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %page The Linux Development Model Introduction What is my affiliation? an independent freelancer, not speaking for any comany working in the Free Software community for many years used to be the maintainer of the Linux firewall netfilter/iptables started many Free Software and Open Hardware projects, e.g. OpenEZX - Open Source for Motorola EZX phones OpenPCD/librfid - 13.56MHz RFID stack OpenBeacon - 2.4GHz active RFID gnufiish - Linux for E-TEN PDA-phones OpenBSC - A GSM backend network BSC+MSC+HLR was employee #1 and Lead System Architect (HW+SW) of Openmoko consulting many companies on FOSS development + licensing %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %page The Linux Development Model What is Free Software? Software that is available in source code is licensed in a way to allow unlimited distribution allows modifications, and distribution of modifications is not freeware, but copyrighted work subject to license conditions, like any proprietary software READ THE LICENSE What is Open Source? Practically speaking, not much difference Remainder of this presentation will use the term FOSS (Free and Open Source Software) %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %page The Linux Development Model What is the FOSS Community? Diverse any individual can contribute no formal membership required every project has it's own culture, rules, ... International the internet boasted FOSS development very common to have developers from all continents closely working together Evolutionary developers come and go, as their time permits projects evolve over time, based on individual contributions %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %page The Linux Development Model People / Groups involved Really depends on size of projects Small projects often a one-man show Bigger project have groups / subgroups Common Terms / Definitions Maintainer The person who formally maintains a project Core Team / Steering Committee A group of skilled developers who make important decisions Subsystem Maintainer Somebody who is responsible for a particular sub-project Developer Community All developers involved with a project User Community Users of the software who often share their experience with others %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %page The Linux Development Model Development Process "Rough concensus and running code" Decisions made by technically most skilled people Reputation based hierarchy Direct Communication between developers Not always driven by size of a target market Release early, release often %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %page The Linux Development Model Motivations (individual) gaining reputation (like in the scientific community) (students) gaining development experience with real-world software solving problems that the author encounters on his computer fighting for Free Software as ideology working on exciting technology without having to work at company XYZ work in creative environment with skilled people and no managers ;) %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %page The Linux Development Model Motivations (corporate) not having to reinvent the wheel if FOSS provides 80% of your problem solution, you just have to add the missing 20% fully customizable, every aspect of the system can be modified/adopted/changed no per-unit royalties be aware, you have more one-time R&D cost %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %page The Linux Development Model Who is "The Community"? Studies show the majority of the Linux kernel code is developed by professional, paid developers most of them work for large IT companies (Intel, Novell, IBM, RedHat, ...) those companies would not invest the development resources if there was no business case for it! So "the community" is not a random collection of individuals scratching their itch but is a group of very prominent professional developers working for some of the biggest IT companies worldwide %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %page The Linux Development Model FOSS Community likes generic solutions portable code vendor-independent architecture clean code (coding style!) open standards good technical documentation raw hardware, no bundle of hardware and software sold as solution %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %page The Linux Development Model FOSS Community dislikes monopolistic structures e.g. intel-centrism closed 'industry forums' with rediculous fees e.g. Infiniband, SD Card Association standard documents that cost rediculous fees NDA's, if they prevent development of FOSS note: Samsungs manuals now under NDA :( %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %page The Linux Development Model Weak Points of FOSS When FOSS is entirely volunteer-driven often way behind schedule (if there is any) already too late when projects start started when there already is a real need often a lack of (good) documentation programmers write code, not enduser docs... strong in infrastructure, weak in applications traditionally developers interested in very technical stuff Thus, FOSS really improves when commercial entities get involved the right way! %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %page The Linux Development Model Windows driver development model MS defines stable APIs and ABIs for drivers and releases SDK (DDK) All interfaces are specified by a single entity The interface between driver and OS core is designed as binary interface Hardware vendors develop drivers for their hardware component Hardware vendors compile and package drivers for their hardware component Hardware vendors sell bundle of hardware and software driver (object code) %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %page The Linux Development Model Linux driver development model A community-driven process creates in-kernel driver API's Drivers are written against those APIs Drivers are submitted to the kernel developes for inclusion into the OS source tree Because all (good) drivers are inside one singe source tree, OS developers can (and will) refine the APIs whenever apropriate There are no stable in-kernel API's, and especially no stable in-kernel ABI's Linux development community releases kernel source code Hardware vendor sells hardware only. The Windows driver CD is unused. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %page The Linux Development Model Linux driver development model Without proper support from HW vendor, Most hardware drivers are developed by people inside that community sadly most of them have no relation to the HW manufacturer even more sadly, many of them have to work without or with insufficient documentation (reverse engineering) Good HW vendors understand this and support Linux properly! Linux is a big market by now Servers Embedded devices (est. > 40% of all wifi/dsl router + NAS appliances) Increasingly popular on the Desktop Recently: Netbooks %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %page The Linux Development Model Linux driver development model, bad case timeline Hardware vendor produces and ships hardware Users end up getting that hardware without any Linux support Somebody will start a driver and inquire about HW docs Hardware vendor doesn't release docs If hardware is popular enough, somebody will start reverse engineering and driver deevlopment With some luck, the driver is actually useable or even finished before the HW product is EOL %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %page The Linux Development Model Linux driver development model, good case timeline #1 Hardware vendor starts Linux driver development for new HW during HW R&D Hardware vendor submits Linux driver for review / inclusion into mainline Linux kernel before HW ships User installs HW and has immediate support by current Linux kernel Hardware vendor publicly releases HW docs when the product ships, or even later This enables the community to support/integrate the driver with new interfaces It also enables the community to support hardware post EOL, at a point where the HW vendor %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %page The Linux Development Model Linux driver development model, good case timeline #2 Hardware vendor releases HW documentation during HW R&D or no later than the product start shipping Somebody in the Linux development community might be interested in writing a driver in his spare time because of technical interest in the HW as a paid contractor by the HW vendor In such cases it helps if the HW vendor provides free samples to trustworthy developers That driver is very likely to get merged mainline %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %page The Linux Development Model Why submit your code mainline? In the PC world Quantity-wise, most users use some Linux distribution Every version of every distribution ships a different Linux kernel version Most end-users are not capable of compiling their own kernel/drives (but way more than you think!) Thus, teaming up with one (or even two, three) Linux distributions only addresses a small segment of the user base distributing your driver independently (bundled with hardware, ...) in a way that is ready-to-use for end-users is a ton of work and almost impossible to get right the preferred option, with the least overhead for both user and HW vendor is to merge the driver mainline. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %page The Linux Development Model Why submit your code mainline? In the embedded/ARM world there are more customers of your SoC than just the tier-1 customers the small/medium size customers do not qualify for your support but if documentation and/or source is availale, they can still buy and use your product the more developers know your product, the more will recommend it in their companies existing experience with a sertain SoC is very valuable, reduces lead time, helps solving problems quickly there are even way more custom distributions in the embedded world you can never support even the smallest fraction of them but all of them use the mainline kernel as base version if your driver + support code is in mainline, all of the distributions will easily run on your SoCs keeping all code in mainline reduces fragmentation of the codebase keeping all code in mainline means you get help with porting and integration with new kernel changes %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %page The Linux Development Model Samsung LSI is part of the community Samsung LSI is part of the community Linux exists because of massive, industry-wide collaboration Only because everyone contributes, Linux Grows Everyone helps to create a better platform If SLSI Linux drivers/support is good, Linux customers prefer SLSI over other vendors Don't only create drivers, but infrastructure (core OS/kernel) Every company does its small part of the Linux kernel R&D %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %page The Linux Development Model How to submit your code mainline? The FOSS code quality requirements are _extremely_ high It's not a surprise that Linux is generally considered much more stable than competitors Code needs to be maintainable Linux supports old hardware ages beyond their EOL Thin of MCA, VLB, Decnet, IPX networking, ... So unless you respect the development culture, your code is likely to get rejected! Post your driver at the respective mailing lists Release early, release often Don't hesitate to ask for feedback and suggestions if you are not 100% sure what is the right way to implement a certain feature %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %page The Linux Development Model Techncal differences In the MS world, almost all interfaces are MS defined In the Linux world, Linux is only the OS kernel All other interfaces are specified by their respective projects Often there are many alternatives, e.g. for graphical drivers X.org project (X11 window server, typical desktop) DirectFB project (popular in embedded devices like TV set-top boxes) Qt/Embedded (popular in certain proprietary Linux-based mobile phones) Every project has it's own culture, including but not limited to coding style patch submission guidelines software license communication methods %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %page The Linux Development Model Practical Rules 1. Much more communication It's not a consumer/producer model, but cooperative! Before you start implementation, talk to project maintainers It's likely that someone has tried a similar thing before It's likely that project maintainers have already an idea how to proceed with implementation Avoid later hazzles when you want your code merged upstream %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %page The Linux Development Model Practical Rules 2. Interfaces If there is a standard interface, use it If insufficient: Don't invent new interfaces, try to extend existing ones If there is an existing interface in a later (e.g. development) release upstream, backport that interface Don't be afraid to touch API's if they're inefficient Remember, you have the source and _can_ change them %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %page The Linux Development Model Practical Rules 3. Merge your code upstream Initially you basically have to create a fork Development of upsteram project continues sometimes at high speed If you keep it out of tree for too long time, conflicts arise Submissions might get rejected in the first round Cleanups needed, in coordination with upstream project Code will eventually get merged No further maintainance needed for synchronization between your contribution and the ongoing upstream development Don't be surprised if your code won't be accepted if you didn't discuss it with maintainers upfront and they don't like your implementation %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %page The Linux Development Model Practical Rules 4. Write portable code don't assume you're on 32bit CPU don't assume you're on little endian if you use assembly optimized code, put it in a self-contained module %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %page The Linux Development Model Practical Rules 5. Binary-only software will not be accepted yes, there are corner cases like FCC regulation on softradios but as a general rule of thumb, the community will not consider object code as a solution to any problem %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %page The Linux Development Model Practical Rules 6. Avoid fancy business models If you ship the same hardware with two different drivers (half featured and full-featured), any free software will likely make full features available on that hardware. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %page The Linux Development Model Practical Rules 7. Show your support for the Community By visibly contributing to the project discussions code equipment By funding developer meetings By making rebated hardware offers to developers By contracting / sponsoring / hiring developers from the community %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %page The Linux Distribution Model The "Linux" System What is a so-called Linux system The Linux operating system kernel The X.org X11 windowing system Various non-graphical system-level software A variety of different desktop systems (KDE, Gnome) A variety of GUI programs In reality, this is a "Linux Distribution" sometimes referred to as "GNU/Linux System" %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %page The Linux Distribution Model Entities in the Linux system Free Software projects and their developers So-called "Distributors" who create "Distributions" Contributors Users Vendors of proprietary Linux software %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %page The Linux Distribution Model FOSS Projects Free Software projects and their developers Linux Kernel, Xorg, KDE, Gnome, Apache, Samba Role Development of the individual program Very focused on their individual project Portability and flexibility usually main concern Interact based on practical neccessity Usually they just provide source code, no object code %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %page The Linux Distribution Model Distributions Distributions (both commercial and community based) Debian, Ubuntu, SuSE, Fedora, RedHat, Mandriva, ... Role Aggregate thousands of individual FOSS programs Find stable and compatible versions of those programs Do 'software system integration' Offer bianary software packages and installation media Offer (security) updates to their users Offer free/best effort or commercial support for professional users %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %page The Linux Distribution Model Contributors Contributors are people not part of a specific development team usually "very active users" of a particular program Role find / document / fix bugs that they find themselves contribute bug reports, documentation or code participate in discussion on features or problems %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %page The Linux Distribution Model Users Users are people just using software Role using programs they usually just install+use a particular distribution they typically do not download+install software directly from the particular software project %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %page The Linux Distribution Model Vendors of Proprietary Software Vendors of proprietary Software (e.g. Oracle) remain a small niche in the Linux world usually driven by a very specific industry they can exist because kernel/userspace ABI is stable! Role feed-back some of their requirements to the Open Source developers help the operating sytestem development to make sure OS is good for them Note: This is not applicable for driver development! drivers are in the Linux kernel, not userspace %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %page The Linux Distribution Model Collaborative Software Development How do projects communicate internally Very rarely in physical meetings (people live too far apart) Very rarely in phone conferences (people live in different timezones) It's almost entirely text-based (e-mails, sometimes chat system) Mailing Lists Usually every project has at least one list Often there are separate lists for developers and users Participation in the mailing list (reading and posting) open to anyone %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %page The Linux Distribution Model Collaborative Software Development Project Management / Decision making usually there's a small group (coreteam) or one leader he is often the creator of the program, or it's maintainer he has the final say in what is accepted or not larger projects have 'subsystem maintainers' with delegated authority so quite often, the structure is more hierarchical than people believe rough concensus and running code %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %page The Linux Distribution Model Motivation of Software Developers Why do developers work on a FOSS project because they're interested in a certain area because it's fun to learn and improve skills because it's fun to co-work with world-class hackers How do people make money often by offering commercial support for their software by offering poerting or system integration by offering development of extensions/modifications by working for a company that uses/needs that program %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %page The Linux Distribution Model Linux and binary compatibility Linux and binary compatibility Drivers usually run inside the OS kernel Linux doesn't have any stable kernel-internal ABI Linux doesn't even have stable kernel-internal API Only the ABI to userspace is stable/fixed Thus, every minor Linux release can break in-kernel ABI+API This is why binary-only drivers simply don't work! %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %page The Linux Distribution Model Linux and binary compatibility I still don't believe! Why not binary-only drivers because every distribution has a different base kernel revision because every distribution can change their kernel version e.g. as part of a security update users will end up in incompatibility nightmare so please, don't do it. It will never work for the majority of your users %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %page The Linux Distribution Model Implications for Hardware Vendors Implications for Hardware Vendors Users are used to get all software from the distribution They are not used to separate vendor-provided driver CD's Thus, drivers need to be in the distribution Goal: getting drivers into the distrubution %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %page The Linux Distribution Model Implications for Hardware Vendors How to get drivers into distributions? You can talk directly to the distributions But: Their code architecture/style requirements are high But: Many of them do not accept binary-only drivers But: There are many, many distributions. Linux is only a certain portion of the market Every distribution is only a small portion of the portion Thus, new goal: Get your drivers in the mainline project %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %page The Linux Distribution Model Implications for Hardware Vendors Getting drivers in the mainline project ensures that all distributions will pick up the driver ensures out-of-the box support of your hardware on all distributions ensures best user experience ensures least internal R&D resources no need to provide binaries for 3 versions of 5 distributions no need to constantly try to catch up with distribution kernel updates %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %page The Linux Development Model Thanks Please share your questions and doubts now! Please contact me at any later point, if you have questions I'm here to help Samsung! hwelte@hmw-consulting.de %center Thanks for your Attention