Nieuwe OpenBSD-versie krijgt ondersteuning voor SMP

De nieuwste versie van OpenBSD, namelijk 3.6, is gisteren vrijgegeven en een van de nieuwe features is de ondersteuning voor symmetric multiprocessing (SMP). Deze feature houdt in dat verschillende processors tegelijk bezig kunnen zijn met aparte processen. SMP in OpenBSD werkt alleen als er gebruikgemaakt wordt van hardware die compatibel is met de AMD64- of de i386-architectuur. Het toevoegen van de SMP-code was relatief weinig werk, omdat er gebruikgemaakt kon worden van relevante code uit de NetBSD-codebase. Veel andere besturingssystemen bieden al ondersteuning voor symmetric multiprocessing. In deze release van OpenBSD 3.6 zijn opnieuw een aantal system daemons herschreven zodat ze niet langer standaard gebruikmaken van het root-account. De ontwikkelaars willen er zo voor zorgen dat het besturingssysteem veiliger is tegen aanvallen en dat de impact van eventuele veiligheidslekken kleiner is.

Reacties (20)

Ik heb niet veel kennis van BSD, maar dit zit toch ook al in de mainstream OS'en als Windows en Linux Of ligt dat nou aan mij en is dit een andere (vorm van) SMP?

Het was nooit een prioriteit van de OpenBSD ontwikkelaars om SMP te ondersteunen. Met de toekomstige dual core processoren is de behoefte aan SMP ook meer aanwezig.
Er is een sponsor geweest die graag SMP ondersteuning in OpenBSD wilde. De ontwikkeling is hiermee in een stroomversenlling gekomen.

[edit] een paar links:
http://marc.theaimsgroup.com/?l=openbsd-tech&m=107951570824676&w=2
http://marc.theaimsgroup.com/?l=openbsd-tech&m=109238313917855&w=2

Dit zit idd al in Linux en Windows.

let op: OpenBSD was de enige BSD die SMP support nog niet had. FreeBSD en NetBSD hadden dit al een behoorlijke tijd.

de aanduiding BSD wordt meestal voor de hele familie gebruikt

Leuk om te zien dat de auteur van dit artikel de interviews (zdnet en onlamp) helemaal niet gelezen heeft. Voor de SMP support is geen gebruik gemaakt van FreeBSD code, maar NetBSD code. En, lang niet alle daemons zijn in 3.6 herschreven. Een aantal draaide al niet als root en een aantal maakte al eerder gebruik van privilege seperation.

Nu is er OpenNTD die door het OpenBSD zelf gemaakt is omdat de vorige onveilig was, ook is er een soort buffer overflow protectie voor het SPARC platform.
Ook ondersteunt deze release hotplugging (eigelijk, een beetje Plug & Play).
Er is ook een nieuw platform beschikbaar voor OpenBSD
En een nieuwe programma waarmee je tcp verbindingen kunt laten vallen

Vind het wel spijtig dat ze geen SMP voor hun PPC distro hebben gemaakt .. in de mac wereld is een dual CPU setup vrij populair ..

Dan moest je misschien toch eens met stewie (fipo) gaan praten?

Ik weet dat Openbsd bij elke nieuwe versie een nieuwe logo maakt. Om het product beter uit elkaar te houden en verschill tussen te houden.

Vind het wel leuk gedaan

En heb ook gehoord dat elk logo ergens voor stond van de versie.

SMP zat al in de PPC versie

edit:
(Onderstaande post is niet helemaal van toepassing, zie ook het commentaar van Onno hieronder.)

Uit het artikel:

Deze feature houdt in dat verschillende processors tegelijk bezig kunnen zijn met aparte processen.

Dit is juist niet wat SMP inhoudt; dit is hoe systemen als OpenBSD, NetBSD en FreeBSD werkten voordat SMP geïmplementeerd werd (en ook NT4 en Linux voor versie 2, trouwens).

Onder moderne besturingssystemen wordt onderscheid gemaakt tussen processen en threads. Als je een executable start wordt er in principe één proces gestart; dit proces bestaat uit een enkele thread (een reeks instructies die achtereenvolgens uitgevoerd wordt). Binnen een proces kunnen meerdere threads gestart worden; dan worden dus min of meer parallel twee procedures uitgevoerd, die wel van gezamelijk geheugen gebruik maken. Dit is bijvoorbeeld het geval als een webbrowser meerdere plaatjes tegelijk wil downloaden; meerdere langlopende threads, die elk niet al te CPU-intensief zijn.

In een systeem met een enkele processor worden verschillende threads niet echt parallel uitgevoerd. De processor voert dan gewoon steeds een paar instructies uit de ene thread uit, en schakelt dan over naar een andere thread. Als er snel genoeg gewisseld wordt, lijken de threads gelijktijdig te executeren. Als een systeem meerdere processoren bevat, onstaan er echter grote problemen doordat twee processoren hetzelfde geheugen moeten benaderen. Nu kan het opeens voorkomen dat twee instructies tegelijkertijd hetzelfde geheugen willen wijzigen. Om problemen hiermee te voorkomen, wordt in traditionele besturingssystemen maximaal één processor aan een proces toegekend. (Vervolgens moeten in de kernel nog wel een aantal voorzorgsmaatregelen worden genomen, maar dat terzijde.)

Dit systeem wordt assymmetric multi-processing genoemd, omdat de processorkracht niet gelijkmatig verdeeld wordt over alle threads. Het werkt heel aardig, omdat beide processoren in principe nuttig werk doen, maar als er één CPU-intensief proces actief is (zoals een grafische applicatie of een game) dan kan deze maar de capaciteit van één processor benutten. Dat is dus niet ideaal. Symmetric multi-processing (SMP) beoogt juist het tegenovergestelde: het gelijkelijk verdelen van processorcapaciteit over alle threads. Dat is dus ook precies wat nu in OpenBSD geïmplementeerd is: verschillende processoren die tegelijk bezig kunnen zijn met hetzelfde proces (en dus niet wat er in het artikel vermeldt staat).

(Interessant detail is dat onder Linux op kernel-nivo bijna geen onderscheid gemaakt wordt tussen processen en threads. Vandaar dat het relatief makkelijk was om SMP onder Linux te implementeren, en Linux had dus relatief vroeg ondersteuning voor SMP.)

Het verschil tussen symmetric en asymmetric MP is niet zozeer het verschil tussen threads en processen, maar het verschil tussen gelijkwaardige en gespecialiseerde processors. In een asymmetrisch systeem verricht elke CPU een bepaalde reeks taken, en de volgende weer andere.

Met alleen processen kun je ook best een SMP systeem hebben, zolang elk proces maar op elke willekeurige processor gegooid kan worden. Het werkt natuurlijk niet altijd zo goed als wanneer je ook threads gebruikt, maar dat is een heel ander punt.

Het hele verschil tussen processen en threads is iets wat binnen je OS en applicaties een rol kan spelen (mbt rechten en adresruimte), maar voor de definitie van SMP zijn die termen irrelevant.

Threads worden trouwens ook wel eens lightweight processen genoemd, en worden soms ook gewoon met behulp van processen geimplementeerd. (zie LinuxThreads..)
(pas in (relatief) recente Unixen zie je echte kernel support voor (p)threads)

Dus vallen over het gebruik van 'processen' door de auteur is niet echt terecht. Ook al omdat het een gewoon Nederlands woord is dat niet speciaal die beveiligings- en adresruimtekenmerken die het binnen OS'en vaak heeft met zich meedraagt.

OpenBSD doet nu trouwens echt pas voor het eerst MP (op x86), het bestond hiervoor helemaal niet. Ook niet op proces-niveau.

Je hebt gelijk; ik ging uit van eigenschappen voor een praktische toepassing van SMP, die technisch gezien niet noodzakelijk zijn. Gelijkwaardige processoren toekennen aan verschillende processen is ook SMP.

Na het lezen van de het artikel waaraan AVL refereert, is me duidelijk geworden dat ze bij OpenBSD nog veel minder ver zijn dan ik dacht. De collega's van FreeBSD zijn juist al twee jaar bezig om het systeem zoals OpenBSD dat nu net heeft ('giant' of 'big' locking), te veranderen in een beter presterende implementatie (fine grained locking). Het was nooit het doel van OpenBSD om vooraan te lopen met ontwikkelingen, maar op deze manier lopen ze naar mijn mening wel erg ver achter.

Mjah dit stond ook al in de meuktracker. Om hier nou apart een FP van te maken vind ik ook een beetje overkill om eerlijk te zijn. Nofi btw.

Hoe dan ook, ik dacht dat OpenBSD altijd al SMP ondersteuning had. Ik vind het ook een beetje opmerkelijk dat ze dit niet eerder heb gedaan. Maja dat zal wel omdat ze uiteraard voor security gaan.

De hele *BSD minnende wereld heeft hier op zitten wachten.
Me dunkt dat hetop de FP staat.

* 786562 bolluserectus

ik weet dat ik hiermee voor de onzinnigste reply ga in dit topic, maar toch: wat een ontzettend lelijk logo....
Ik dacht dat die *BSD varianten allemaal een blowfish als logo hadden? Dit lijkt meer op een kruising tussen een blowfish en Loeki.
Hier staan meer logo\\\\\\\'s, de oudere zijn duidelijk mooier dan de nieuwe.

Wat de pinguin voor Linux is, is de Daemon demon voor *BSD. De blowfish is typisch OpenBSD/OpenSSL.

Maar ik denk dat elke BSD gebruiker het met mij eens is: eerst goede software, dan een cool logo

Meer informatie over OpenBSD 3.6, SMP support en een interview met core developers kun je bij OnLamp vinden:

http://www.onlamp.com/pub/a/bsd/2004/10/28/openbsd_3_6.html

wat ik me af vraag is wie er nou een systeem wil dat zo ver achterloopt op de rest? waarom openbsd gebruiken als ze nog niet eens dingen kunnen die linux of freebsd al jaren kunnen? alhoewel ik niet weet hoe ver openbsd in z'n ontwikkeling zit, klinkt het me toch een beetje als Linux 2.0

volgens mij kunnen beter wat meer code forken uit andere bsd's om hun codebase weer een beetje up to date te brengen, anders is openbsd over een paar jaar gewoon verdwenen...

Misschien loopt OpenBSD enigsinds achter met betrekking
to SMP, maar op beveiligingsgebied zijn ze duidelijk trendsetter. In de afgelopen jaren zijn baanbrekende technieken ontwikkled dorr het OpenBSD team.
Lees meer op [url="http://www.openbsd.org."]www.openbsd.org.[/url]