embedded Linux, van Black Tot QA
Upcoming SlideShare
Loading in...5
×
 

embedded Linux, van Black Tot QA

on

  • 1,219 views

Dutch: Het bouwen van een embedded Linux systeem lijkt vaak op toveren. Toch kan het ook met een systematische aanpak. Dat is goedkoper en levert een beter product op. Op een pragmatische manier wordt ...

Dutch: Het bouwen van een embedded Linux systeem lijkt vaak op toveren. Toch kan het ook met een systematische aanpak. Dat is goedkoper en levert een beter product op. Op een pragmatische manier wordt getoond hoe die, o-zo belangrijke "herhaalbaarheid" voor embedded systemen, ook met embedded Linux mogelijk is.

Statistics

Views

Total Views
1,219
Views on SlideShare
1,201
Embed Views
18

Actions

Likes
0
Downloads
3
Comments
0

4 Embeds 18

http://albert.mietus.nl 14
http://www.slideshare.net 2
http://www.linkedin.com 1
https://www.linkedin.com 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

embedded Linux, van Black Tot QA embedded Linux, van Black Tot QA Presentation Transcript

  • ‘ m Linux’ bouwen: black-art of QA-proces ? © ALbert Mietus, PTS software BV
  • Begrippen [Hidden sheet]
    • m Linux Embedded Linux (verkorte schijfwijze)
    • E- m Linux Easy/Embedded Linux (inclusief tools)
          • ( E- * is ‘naam’ van mijn generieke bouw-omgeving)
    • QA Quality Assurance (verkorte schijfwijze)
    • Kernel Kern-deel van een OS (Linux is een kernel)
    • Tools (hier) Aanvulling op ( Linux )kernel, om volledig OS te krijgen
            • E.G. shell(s), ls, mkdir,cron, ssh, ftp
    •  Busybox Set van tools, speciaal voor m Linux
    •  thttpd Kleine web-server, bijvoorbeeld voor embedded systemen.
  • Agenda
    • Linux, … by magic
        • Zo doet u het (toch) niet
    • QA, wat & waarom
        • beheer & reproduceer
    • m Linux & QA
        • de kunst van automatisch bouwen
        • van kunstwerk tot maatwerk
  • Linux, … by Magic Ofwel: Hoe komt uw buurman aan zijn Linux?
  • Linux, by magic
    • Linux wordt gebouwd door super-specialisten
      • Grote delen komen rechtstreeks van het internet
      • Delen worden geïntegreerd totdat het niet meer werkt
      • Patches (bugfix) worden gebruikt, zodra ze beschikbaar zijn
    • Het enige dat telt: is een ‘gratis’ OS , liefst ASAP!
    Throw know-how away (important!) Add Tools Try-out OK? Mostly not Sometimes Kernel x.y Config
  • TovernaarsVragen
    • Welke features zitten er in MagicLinux ?
    • Bevat onzeLinux ook bugfix <No> ?
    • Wat is het verschil met de vorige release ?
    • Zijn er verder geen verschillen ?
    • Zeker weten?
    • Deze vragen blijven vaak onbeantwoord!
  • Q uality A ssurance ‘ Zeker weten wat de kwaliteit is’
  • QA, traditioneel
    • QA is vaak een zwaar proces dat probeert te verzekeren dat, in een complexe omgeving, een ingewikkelde verandering voldoende succesvol is.
    • QA is gericht op het proces, niet het product!
    • QA levert niet direct kwaliteit, maar probeert die kwaliteit constant te houden
    • Effect: veel overhead, input van ‘buiten’ niet vertrouwen
  • Kwaliteit in embedded systemen
    • Voor embedded systemen is het eenvoudig
    • Het ‘doosje’ moet altijd werken.
      • Zo niet, dan zal de klant
        •  Het opnieuw proberen
        •  Een paar tikjes op het systeem geven
        •  Het systeem weggooien
          • En een nieuwe kopen, soms van de concurrent
    • Met andere woorden :
        • Zorg dat u weet wat u levert!
        • Goedkoop? => foutjes worden geaccepteerd
  • QA in embedded systemen
    • QA kan (dus) veel eenvoudiger
      •  De Q-eis is veel eenvoudiger: ‘altijd werken’
      •  De omgeving is eenvoudiger: ‘het doosje’
      •  De verandering is eenvoudig: ‘…’
      •  De SW is relatief klein van omvang.
    • QA in embedded systemen moet gericht zijn op de ‘in ontwikkeling zijnde’ revisie!
        • Want er is (vaak) maar één release
  • Linux & QA Ofwel: Hoe ‘ uw Embedded-Linux ’ bouwen?
  • QA en Linux
    • PRAGMA'S
            • (Kom naar de stand voor uitleg)
      • Vertrouw Linux
          • Zeker het deel dat veel gebruikt is.
      • Vertrouw eigen veranderingen NIET
          • Die zijn te ‘weinig’ gebruikt.
      • Vertrouw het bouwen ‘ by magic ’ NIET
          • Dat is niet herhaalbaar.
      • Vertrouw uw kennis
          • En leg deze vast!
      • Voorkom overhead
          • Altijd een goed idee
  • Eenvoudig QA in Linux
    • QA in Linux kan, door:
      • Het ‘ by magic ’ proces te standaardiseren
      • Te concentreren op ‘eigen inbreng’
            • De Q van ‘veel’ is goed genoeg
    • Pragmatische aanpak:
        • automatisch bouwen
        • modulair bouwen
    • Effect:
        • (operationele) QA-kosten zijn nihil (of minder!)
  • Automatisch bouwen
    • Bouw automatisch, aan de hand van een configuratie file
      • Deze configuratie:
        • bevat:
          • versienummers, filenamen, download-sites, bouwopties, etc, ...
          • patches met eigen opties, modificaties, etc, …
        • wordt beheerd en ‘opgeleverd’
    • Bouwen met gelijke configuratie geeft hetzelfde resultaat
    Configfile(s) TEST co/ verbeter /ci Versie Beheer insert/check fetch patch unzip install make File-list
  • Voorbeeld
    • Template 1
    • Versie beheer info
    • Relatief pad
    • Wat we bouwen Welke versie En onze veranderingen (hier: config data)
    • default: busybox-0.60.5
    • Ja, het is een ‘Makefile’ Type: port
    # ConfigFile, for E- m Linux # $Id: GNUmakefile,v 1.7 2003/09/18 12:20:37 GAM Exp $ # Where is YourEmbeddedLinux? TOPDIR = ../../../. #Module settings PORTNAME = busybox PORTVERSION = 0.60.5 PATCHES = patch-aa patch-ba # Install options ... INSTALLOPT =&quot;PREFIX=${LIVEDIR}&quot; ## Overrule the default Epkg-name #PKGNAME = include ${TOPDIR}/Mk/port.mk
  • Modulair bouwen
    • Opdelen op in (sub)modules
        • Linux, busybox, thttpd, shell(s), …
        • eigenApplicaties, …
    • Per (sub)module een configuratiefile
        • Er kan dus per module gebouwd, getest en beheerd worden
    • Speciaal type configuratiefile: ‘dir’ (of: ‘module’)
      • Bepaalt de bouwvolgorde (sub)modules
      • DUS : ook dat (kan) beheerd & gecontroleerd worden
  • Voorbeeld
    • Een iets andere template
    • Zie ook 2 sheets terug
    • Alle (sub)modules elk in een eigen directory Volgorde is (hier) niet belangrijk
    • Als nodig, leg de gewenste bouwvolgorde (hier) vast
    • Een ander ‘template’ Type: subdir
    # ConfigFile, for E- m Linux # $Id: GNUmakefile,v 1.21 2003/09/18 13:28:17 ami Exp $ # Where is YourEmbeddedLinux ? TOPDIR= ../../. # Modules to build SUBDIRS += busybox SUBDIRS += links e2fsprogs SUBDIRS += thttpd dhcpcd SUBDIRS += bash dcron netkit SUBDIRS += linux-utils isdn4k-utils #Order to build (“After”: “Before”) busybox: bash include ${TOPDIR}/Mk/subdir.mk
  • QA-‘niveau(s)’
    • Er is altijd een afweging: (bij gelijke functionaliteit)
        • kosten  kwaliteit .
      • We kunnen dit instellen, door meer of minder ‘ config checks ’ in de configfile op te nemen.
        • md5-checksums  chrooted bouwen
        • File-list  versies van compilers e.d.
      • Het maakt de bouwomgeving duurder
          • (ontwerp, diskruimte, configuratietijd, bouwtijd, …)
      • Maar geeft een grotere garantie op kwaliteit
    • Dit is een ‘management keuze’!
  • Samenvatting & Conclusies (1)
    •  Bouw ‘ m Linux’ door kennis vast te leggen!
            • Vastleggen == documenteren==controleerbaar==herhaalbaar
    •  Externe Wizards helpen niet
            • Dan wordt ‘ by Magic ’ slechts verborgen
    •  Beheer[s] de (module)configuraties
            • Het eigen team moet het beheer s en
    •  Investeer in een maatwerk bouwomgeving
            • Hier is vaak wel externe kennis nodig
    •  Concentreer op ‘eigen … <<inbreng>> …’
            • Wat extern veel gebruikt is, is vast wel goed
  • Samenvatting & Conclusies (2)
    •  QA van ‘Linux’ is mogelijk en eenvoudig
            • Dit hebben we laten zien
    •  Concept is belangrijkste, daarna pas tooling
            • Tools maken het efficiënter, niet beter
    •  Kies een kwaliteitsniveau, dat past
            • Nog beter, is ook complexer en duurder
    •  Kies tools voor ‘ m Linux’
            • Kan die ‘mooie’ overweg met embedded beperkingen?
    •  ‘ Just do it’! (en verbeter, zodra nodig)
            • Begin goedkoop, verbeter tot het benodigde niveau!
  • Voor vragen en discussie Bij de PTS (stand 17) of info@ PTS .nl (Vanwege de krappe tijd) Dank voor uw aandacht!