embedded Linux, van Black Tot QA

‘ 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 ="PREFIX=${LIVEDIR}" ## 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!

embedded Linux, van Black Tot QA

by Albert Mietus on Feb 18, 2010

Accessibility

Categories

Tags

Upload Details

Usage Rights

2 Embeds 10

Statistics

embedded Linux, van Black Tot QA — Presentation Transcript

http://albert.mietus.nl	8
http://www.slideshare.net	2