Bitrig - ein neuer OpenBSD-Fork

[h^2]

Wie die Phoronix-leser (und die OpenBSD-Insider) wahrscheinlich schon wissen gibt es einen neuen OpenBSD-Fork: Bitrig

http://www.bitrig.org
http://www.phoronix.com/scan.php?page=news_item&px=MTExODY

Was haltet ihr davon? Und was fuer Leute stehen dahinter?

Ein paar der Gruende nicht mehr an OpenBSD zu arbeiten, die sie nennen sind, dass sie weniger konservativ und dafuer feature-freundlicher sein wollen. Die Base soll kleiner werden, clang einziehen, Fokus auf i386+amd64+arm, das Giant-Lock fallen...
Das hoert sich aus meiner Sicht sinnvoll an, aber ich frage mich schon, dass wenn man den Konservatismus von OpenBSD aufgibt (der vielleicht viel der Sicherheit ausmacht), wo liegt dann der Vorteil ueberhaupt mit der OpenBSD-Base zu arbeiten? Warum nicht gleich ein anderes BSD, was wenigstens einige der Ziele schon erreicht hat und bei den anderen auf dem Weg ist?
Gerade DfBSD sollte doch von der community her so klein sein, dass eine handvoll gute Entwickler auch wirklich mitmischen koennen...

 

[Elwood]

Für diese (eher schwachen) "Goals" wäre mir persönlich ein Fork zu viel Arbeit. Aber wer's braucht.

 

[hawky]

im ersten moment denkt man ja immer gleich, dass nun entwickler von openbsd abspringen und nicht mehr zur verfuegung stehen.

aber selbst wenn es so ist, dann wird die arbeit dieser leute am fork auch wieder openbsd befruchten.

vielfalt bedeutet auch mehr inspiration und kreativitaet ... von daher freu ich mich und schau mal was da entsteht.

--hawky

 

[darktrym]

Schwer vorzustellen, dass das Projekt länger leben wird. Es sind doch größtenteils NetBSD/FreeBSD Feature die eingebaut werden sollen.

Item Description Comments
llvm/clang support Kernel, userland, and xenocara compiled with clang Completed
KVM support Add kernel and user space changes to support KVM
WAPBL support Add a journaling filesystem
ARM support Add support for beagle and panda board
Fine grained MP Get rid of biglock
FUSE/puffs support Add kernel and user space pieces to support FUSE functionality.
Support latest GNU binutils Port latest GNU binutils in order to get things like gold and LTO Rewrite anyone?
Port libc++ to Bitrig In order to remove need for libstdc++
Port compiler-rt to Bitrig In order to remove need for libgcc.a

 

[Yamagi]

Vor einiger Zeit hatten wir im IRC eine heftige Diskussion darüber, weshalb NetBSD und OpenBSD zunehmen an Boden verlieren. Ich warf zu OpenBSD ein, dass das Projekt im ganz wesentlichen Thema "SMP" die Zeit völlig verpennt hätte und untergehen wird, wenn es nicht bald den Hintern hochbekommt. Erstaunlicherweise kam aus der OpenBSD-Ecke fast nur Zustimmung. OpenBSD mag ein sehr gutes, stabiles und sicheres System sein. In den beiden Punkten vielleicht mehr, als jedes andere auf dem Markt. Aber wir leben in einer Zeit, wo die ganz großen Eisen mehr als 100 CPUs haben. Jeder Desktop hat 2 bis 8, ein Handy meist 4 und selbst Netzwerkinfrastruktur mindestens 2 Stück... Was nützt mir die beste Sicherheit, die höchste Stabilität, wenn ich einen Großteil meiner Ressourcen nicht nutzen kann, da die Software einfach nicht über mehrere CPUs skaliert? Und das wird in den nächsten Jahren mit steigenden CPU-Anzahlen eine immer relevantere Frage werden. Ein im Kern fast 40 Jahres altes System fit für das SMP-Zeitalter zu machen ist wahrlich nicht einfach und ich verstehe, dass die OpenBSD-Entwickler Angst vor den sich ergebenden Konsequenzen (massive Änderungen der Struktur und des Codes an sich notwendig, sehr hohes Risiko hunderte neue Bugs einzubauen, eine ganz neue Klasse an Fehlern, etc.) haben. FreeBSDs SMPng ist sicher das beste Argument gegen einen solchen Umbau. Aber durch den Kopf in den Sand stecken und abwarten, wird die Lage nicht auf magische Weise besser. Und es ist nur ein Punkt. Von den Herausforderungen >100GB RAM zu verwalten, >10TB Dateisysteme performant zu implementieren und so weiter reden wir noch gar nicht. So gesehen verstehe ich durchaus, dass einige Personen nicht mehr dem "Verfall" zuschauen möchten, stattdessen die Sache selbst in Hand nehmen.

Nur ist es die Lösung aller Probleme? Nein. Erstmal ist es nicht damit getan, sich ein Wochenende hinzusetzen und mal eben den GIANT rausnehmen. Das ist ein Projekt. was selbst in seiner kleinstmöglichen Umsetzung Jahre in Anspruch nehmen wird. FreeBSDs sehr umfassende Lösung hat fast 8 Jahre gebraucht, Linux (wo BKL aber nie die Auswirkungen unseres GIANTs hatte) benötigte ebenfalls >5 Jahren um nur die hauptsächlichen Codepfade zu ändern. NetBSDs "einfache" Lösung ebenfalls Jahre. Daher ist es stark zu bezweifeln, dass dieser Fork die Manpower und die notwenige Hingabe mitbringt, das Vorhaben umzusetzen. Vor allem aber wird sich dadurch in der ersten Zeit der Code ohne sichtbare Vorteile destabilisieren. Wird man die sich ergebende Durststrecke durchhalten? Man muss sich die Frage stellen, ob OpenBSD selbst den Rückstand je aufholen kann, ohne seine Nutzer zu verprellen. Das so ein Fork es schafft, ist fast ausgeschlossen. Wie Elwood andeut, wäre der umgekehrte Weg vielleicht besser. OpenBSDs "Sicherheitstechnik" auf FreeBSD portieren.

Überhaupt stehe ich nach wie vor auf dem Punkt, dass ca. 95% aller Forks mehr schaden als nützen. Sind es Entwickler des Urprojektes, die forken? Dann ziehen sie die meist eh schon stark begrenzten Ressourcen eines Projektes weiter auseinander, sodass am Ende weder Original noch Fork die notwendige Manpower haben. Gut bei ffmpeg / libav / mplayer / mplayer2 zu sehen. Das libav und ffmpeg noch nicht ganz tot sind, liegt hauptsächlich an Red Hats bezahlen Codesklaven. Bei mplayer und mplayer2 drehen sich beide seit Monaten im Kreis, keines der beiden Projekte hat was sinnvolles zustande gebracht, wenn man mal von Bugfixes absieht. Und so läuft es öfter, als die "Basar-Fraktion" wahrhaben will. Und wenn der Fork nicht aus dem Originalprojekt kommt, zieht er noch immer die Nutzerbasis auseinander, spaltet sie, treibt einen Keil ins Ökosystem. Da Nutzer aber die Basis jedes erfolgreichen Opensource-Projektes sind, kann ein Verlust eines Teils der Nutzerbasis schnell sehr problematisch werden. Dies war zum Beispiel bei X.org vs. XFree86 einer der Hauptgründe für den Niedergang des Originalprojekts. So muss man sich die Frage stellen, ob dieser Fork nicht am Ende OpenBSD mehr schadet, als insgesamt der Sache zu nützen und ob ein Engagement im Orginalprojekt - oder halt woanders - nicht insgesamt sinnvoller wäre.

 

[h^2]

Ich teile Yamagis Einschaetzung, deswegen auch meine Frage: was sind real Dinge in der OpenBSD-base, die siginifikant besser/neuer/schneller/sicherer sind, ausser, dass es durch geringere Komplexitaet, weniger features und weniger Veraenderung eben konservatirver ist. [ diese aufgezaehlten Punkt verliert ja jeder Fork, der versucht die Probleme zu beheben. ]

Bei DfBSD und NetBSD gibt es immerhin Innovationen, wenn auch nicht sicher ist, ob sie je allgemeine Reife erlangen. Das heisst, hier gehen Menschen immernoch neue Pfade, die sie vielleicht aus dem Research-OS-Status (Sorry, wenn ich DfBSD und NetBSD s bezeichne) irgendwann rausholen, oder zumindest anderen Betriebsystemen nutzen.

 

[mark05]

hi
nix fuer ungut aber , auch wenn ich einige punkte von yamagi's arrgumentation nachvollziehen
kann, so vermisse ich nix bei obenbsd und bin auch froh ueber das "konserative"

ich nutze openbsd fast nur im infrastruktur bereich , sprich firewall , router , dhcp server etc.

und da ist es einfach perfekt gerade mit den hoch verzahnten daemons zum kernel und carp.

was smp betrifft ich vermisse da nix ....... es gibt smp welches auch funktioniert.
es ist bestimmt nicht so gut wie das was es fuer freebsd und linux gibt aber es ist
funktional und stabil.

so stabil das es per default aktiv ist bei der installation.

ich weiss auch das bestimmte technologieren unter der beobachtung stehen fuer eine
implementation z.b. das neue hammerfs 2.0 kann durchaus einzu in openbsd halten
wenn es den fertig ist.

bei pf habe ich noch nie probleme gehabt was performance betrifft obwohl ich
hier mit bandbreiten von bis zu 8x !gbit im routing und packetfilter rede.

und da spielt smp eh keine rolle.

und mir kann auch keiner erzaehlen das smp im packetfilter bereich sinn macht.

von daher wozu fork .

man sollte sein os nach gestellter aufgabe waehlen und nicht nach den vorhandenen features (die im zeiwefel keiner braucht )


holger

 

[darktrym]

Dann schau dir mal die Baustellen an:

• SMP
• Kernelmodule
• KMS, GEM, TTM - X ohne Rootrechte (der Intel Kram zählt nicht, der ist ein ziemliches Zusammengefrickel)
• Virtualisierung
• Compilerinfrastruktur

Irgendwann machts auch dann den Entwicklern keinen Spaß mehr.

 

[mark05]

Dann schau dir mal die Baustellen an:

• SMP
• Kernelmodule
• KMS, GEM, TTM - X ohne Rootrechte (der Intel Kram zählt nicht, der ist ein ziemliches Zusammengefrickel)
• Virtualisierung
• Compilerinfrastruktur

Irgendwann machts auch dann den Entwicklern keinen Spaß mehr.

smp ist vorhanden.
kernelmodule wozu ?
X auf einem router oder firewall braucht man nicht.
virtualisierung ? ne firewall ? eine bridge ? einen openbgpd router ?
nein danke.

zu themen wie complierfrage kann ich nix sagen aber ich sehe
dsa eher aus anwendersicht und das ist mir eine gute documentation wichtiger
als virtualisierung oder comiler fragen.

virtualisierung geht mir mittlerweile eh auf den sack , weil man sich immer
mehr rechtferigien muss warum man bestimmte dinge nicht virtualisieren will.

holger

 

[lme]

im ersten moment denkt man ja immer gleich, dass nun entwickler von openbsd abspringen und nicht mehr zur verfuegung stehen.

aber selbst wenn es so ist, dann wird die arbeit dieser leute am fork auch wieder openbsd befruchten.

Vielleicht Anfangs. Aber wenn sich beide Projekte weiterentwickeln ist wird es schon nach kurzer Zeit immer schwieriger, Code vom jeweils anderen Projekt zu übernehmen.
So werden beispielsweise auch nur noch hauptsächlich Userland-Tools zwischen den BSDs ausgetauscht, weil die Kernel längst vollkommen unterschiedlich sind. Selbst beim letzten Fork DragonFly und Väterchen FreeBSD.

 

[darktrym]

smp ist vorhanden.
kernelmodule wozu ?
X auf einem router oder firewall braucht man nicht.
virtualisierung ? ne firewall ? eine bridge ? einen openbgpd router ?
nein danke.

zu themen wie complierfrage kann ich nix sagen aber ich sehe
dsa eher aus anwendersicht und das ist mir eine gute documentation wichtiger
als virtualisierung oder comiler fragen.

virtualisierung geht mir mittlerweile eh auf den sack , weil man sich immer
mehr rechtferigien muss warum man bestimmte dinge nicht virtualisieren will.

holger

SMP in Form eines BKL, dass ist schon seit einen Jahrzehnt nicht mehr Stand der Technik.
Kernelmodule um andere Lizenzen zu unterstützen, Minimalisierung des Kernel, statt irgendwelche Optionen ein- bzw. auszukommentieren und neu zu übersetzen.
OpenBSD ist nicht nur für Router interessant, auch müssen die Entwickler darauf können.
Schon alleine wegen der mangelnder UX bei Anfänger gehen denen einen Haufen Tester verloren.
Die Serverperformanz ist auch eher unterdurchschnittlich.
Der Compiler ist völlig veraltet, selbst NetBSD ist da weiter.
Und zu Virtualisierung: Gibts denn diese überhaupt bei OpenBSD, Xen, kvm, Virtualbox?

Ein OS was nur auf Nischen setzt, ist dem Untergang geweiht.

 

[mark05]

SMP in Form eines BKL, dass ist schon seit einen Jahrzehnt nicht mehr Stand der Technik.

und funktioniert ......

Kernelmodule um andere Lizenzen zu unterstützen, Minimalisierung des Kernel, statt irgendwelche Optionen ein- bzw. auszukommentieren und neu zu übersetzen.

ich haben in den letzen 5 jahren kaum einen neuen kernel bauen muessen und
wenn das nur um ipmi zu aktivieren.

OpenBSD ist nicht nur für Router interessant, auch müssen die Entwickler darauf können.
Schon alleine wegen der mangelnder UX bei Anfänger gehen denen einen Haufen Tester verloren
.

sorry aber auf diese linux juenger kann man verzichten denen ist systemd
und udev und was auch immer wichtiger als ein sichers system.

Die Serverperformanz ist auch eher unterdurchschnittlich.

das kann ich nicht viel zusagen das ich openbsd nicht als server os
nutze.
zum teil aus den hier , auch von dir , genannten punkten.

hatte das auch schon eine kontroverse diskussionen mit henning .
jedoch kommt das immer ein argument was ich gut nachvollziehen kann.

wenn openbsd was macht das richtig , auch wenn es jahre spaeter ist.

Der Compiler ist völlig veraltet, selbst NetBSD ist da weiter.

interessiert mich als anwender herzlich wenig sollange es funktioniert.

Und zu Virtualisierung: Gibts denn diese überhaupt bei OpenBSD, Xen, kvm, Virtualbox?

und auch hier wozu brauche ich das auf einem os was hauptsaechlich
im infrastruktur bereich genutzt wird und auch dort der fokus der entwicklung
liegt. ?

mir wird schlech bei dem gedanken das es menschen gibt die ihre firewall
in einer virtualisierten umgebung laufen lassen .

Ein OS was nur auf Nischen setzt, ist dem Untergang geweiht.

sehe ich nicht so , mit ist ein os was das was es macht richtig gut macht
leiber als so ne frickelbude ala linux was alles koennen soll aber davon
nix richtig.

handwerker haben auch mehere arten von schraubendreher immer passend
zur schraube.

oder wie mein meister immer gesagt hat " verwende immer das richtige werkzeug
zu dem was du vorhast. "

holger

 

[Kamikaze]

smp ist vorhanden.

Userland SMP ist gerade bei Infrastukturhardware doch weniger nützlich. Wenn du mit PF einen Backbone betreiben willst, wäre SMP im Kernel wirklich sinnvoll. Und in absehbarer Zukunft unabdingbar. Sonst bleibt die Leistung die meiste Zeit Dunkel, weil nur ein Kern Pakete routen darf und die anderen sich langweilen.

 

[jmt]

Aus meiner Erfahrung mit OpenBSD kann ich nur sagen, dass es einfach funktioniert. Und man kann es problemlos Updaten. Wenn ich jedoch die Eigenschaften von Bitrig haben möchte, dann nehme ich halt ein NetBSD. Ich finde, dass man gerade bei DragonflyBSD sehr gut sehen kann, dass es mit ein paar neuen Features nicht getan ist. DragonflyBSD krankt daran, dass sie nur mit Mühen ihr Base-System auf einem aktuellen Stand halten können. Dabei sind die Features, die DragonflyBSD hat, bedeutender als die, die Bitrig haben will.

 

[mark05]

Userland SMP ist gerade bei Infrastukturhardware doch weniger nützlich. Wenn du mit PF einen Backbone betreiben willst, wäre SMP im Kernel wirklich sinnvoll. Und in absehbarer Zukunft unabdingbar. Sonst bleibt die Leistung die meiste Zeit Dunkel, weil nur ein Kern Pakete routen darf und die anderen sich langweilen.

was hest den hier userland smp ?

userland heist fuer mich anflanschloesung ala fuse-zfs bei linux

also zeug was zur laufzeit zum kernel hinzugefuegt wird.
und das ist nicht der fall beim smp von openbsd.

holger

 

[hawky]

mal aus reiner anwendersicht:

ich nutze openbsd seit 2.7 auf infrastruktur-hw und auch privat auf meinen workstations. es gibt nichts was ich vermisse - im gegenteil ... und ich hatte nie performance-probleme.

was mir nicht gefaellt ist lediglich das design der cd-huellen (sieht mir echt zu verspielt aus ;-) und ich wuerde mir auf undeadly.org einen regelmaessigen newsletter wuenschen!!!

 

[jmt]

was hest den hier userland smp ?

Kamikaze meint hiermit wohl, dass nur jeweils 1 Thread im Kernel verarbeitet wird.

 

[mark05]

Kamikaze meint hiermit wohl, dass nur jeweils 1 Thread im Kernel verarbeitet wird.

naja das gehen wohl 8 threads im kernel be dieser kiste

was fuer ne firewll wohl genug ist.

holger

OpenBSD 5.1 (car-4003.mp) #3: Wed Mar 7 18:18:06 CET 2012
root@inhouse-fw2:/usr/src/sys/arch/amd64/compile/car-4003.mp
real mem = 4285005824 (4086MB)
avail mem = 4156776448 (3964MB)
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xfc860 (68 entries)
bios0: vendor American Megatrends Inc. version "080015" date 05/02/2011
acpi0 at bios0: rev 2
acpi0: sleep states S0 S1 S3 S4 S5
acpi0: tables DSDT FACP APIC MCFG OEMB HPET SSDT
acpi0: wakeup devices P0P1(S4) P0P3(S4) P0P4(S4) P0P5(S4) P0P6(S4) BR1E(S4) EUSB(S4) USB0(S4) USB1(S4) USB2(S4) USB3(S4) USBE(S4) USB4(S4) USB5(S4) USB6(S4) GBE_(S4) BR20(S4) BR21(S4) BR22(S4) BR23(S4) BR24(S4) BR25(S4) BR26(S4) BR27(S4) SLPB(S4)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee00000: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Xeon(R) CPU X3450 @ 2.67GHz, 2660.37 MHz
cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,NXE,LONG,LAHF
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: apic clock running at 132MHz
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Xeon(R) CPU X3450 @ 2.67GHz, 2660.00 MHz
cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,NXE,LONG,LAHF
cpu1: 256KB 64b/line 8-way L2 cache
cpu2 at mainbus0: apid 4 (application processor)
cpu2: Intel(R) Xeon(R) CPU X3450 @ 2.67GHz, 2660.00 MHz
cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,NXE,LONG,LAHF
cpu2: 256KB 64b/line 8-way L2 cache
cpu3 at mainbus0: apid 6 (application processor)
cpu3: Intel(R) Xeon(R) CPU X3450 @ 2.67GHz, 2660.00 MHz
cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,NXE,LONG,LAHF
cpu3: 256KB 64b/line 8-way L2 cache
cpu4 at mainbus0: apid 1 (application processor)
cpu4: Intel(R) Xeon(R) CPU X3450 @ 2.67GHz, 2660.00 MHz
cpu4: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,NXE,LONG,LAHF
cpu4: 256KB 64b/line 8-way L2 cache
cpu5 at mainbus0: apid 3 (application processor)
cpu5: Intel(R) Xeon(R) CPU X3450 @ 2.67GHz, 2660.00 MHz
cpu5: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,NXE,LONG,LAHF
cpu5: 256KB 64b/line 8-way L2 cache
cpu6 at mainbus0: apid 5 (application processor)
cpu6: Intel(R) Xeon(R) CPU X3450 @ 2.67GHz, 2660.00 MHz
cpu6: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,NXE,LONG,LAHF
cpu6: 256KB 64b/line 8-way L2 cache
cpu7 at mainbus0: apid 7 (application processor)
cpu7: Intel(R) Xeon(R) CPU X3450 @ 2.67GHz, 2660.00 MHz
cpu7: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,NXE,LONG,LAHF
cpu7: 256KB 64b/line 8-way L2 cache
ioapic0 at mainbus0: apid 8 pa 0xfec00000, version 20, 24 pins
ioapic0: misconfigured as apic 1, remapped to apid 8
acpimcfg0 at acpi0 addr 0xe0000000, bus 0-255
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (P0P1)
acpiprt2 at acpi0: bus 5 (BR1E)
acpiprt3 at acpi0: bus -1 (BR20)
acpiprt4 at acpi0: bus -1 (BR21)
acpiprt5 at acpi0: bus -1 (BR22)
acpiprt6 at acpi0: bus -1 (BR23)
acpiprt7 at acpi0: bus -1 (BR24)
acpiprt8 at acpi0: bus -1 (BR25)
acpiprt9 at acpi0: bus -1 (BR26)
acpiprt10 at acpi0: bus -1 (BR27)
acpicpu0 at acpi0: C3, C2, C1, PSS
acpicpu1 at acpi0: C3, C2, C1, PSS
acpicpu2 at acpi0: C3, C2, C1, PSS
acpicpu3 at acpi0: C3, C2, C1, PSS
acpicpu4 at acpi0: C3, C2, C1, PSS
acpicpu5 at acpi0: C3, C2, C1, PSS
acpicpu6 at acpi0: C3, C2, C1, PSS
acpicpu7 at acpi0: C3, C2, C1, PSS
acpibtn0 at acpi0: SLPB
acpibtn1 at acpi0: PWRB
ipmi0 at mainbus0: version 1.5 interface KCS iobase 0xca2/2 spacing 1
cpu0: Enhanced SpeedStep 2660 MHz: speeds: 2667, 2533, 2400, 2267, 2133, 2000, 1867, 1733, 1600, 1467, 1333, 1200 MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel Core DMI" rev 0x11
ppb0 at pci0 dev 3 function 0 "Intel Core PCIE" rev 0x11
pci1 at ppb0 bus 1
ppb1 at pci0 dev 4 function 0 "Intel Core PCIE" rev 0x11
pci2 at ppb1 bus 2
em0 at pci2 dev 0 function 0 "Intel I340-T4 (82580)" rev 0x01: msi, address 00:90:fb:3a:c1:12
em1 at pci2 dev 0 function 1 "Intel I340-T4 (82580)" rev 0x01: msi, address 00:90:fb:3a:c1:13
em2 at pci2 dev 0 function 2 "Intel I340-T4 (82580)" rev 0x01: msi, address 00:90:fb:3a:c1:14
em3 at pci2 dev 0 function 3 "Intel I340-T4 (82580)" rev 0x01: msi, address 00:90:fb:3a:c1:15
ppb2 at pci0 dev 5 function 0 "Intel Core PCIE" rev 0x11
pci3 at ppb2 bus 3
em4 at pci3 dev 0 function 0 "Intel I340-T4 (82580)" rev 0x01: msi, address 00:90:fb:37:74:0a
em5 at pci3 dev 0 function 1 "Intel I340-T4 (82580)" rev 0x01: msi, address 00:90:fb:37:74:0b
em6 at pci3 dev 0 function 2 "Intel I340-T4 (82580)" rev 0x01: msi, address 00:90:fb:37:74:0c
em7 at pci3 dev 0 function 3 "Intel I340-T4 (82580)" rev 0x01: msi, address 00:90:fb:37:74:0d
ppb3 at pci0 dev 6 function 0 "Intel Core PCIE" rev 0x11
pci4 at ppb3 bus 4
em8 at pci4 dev 0 function 0 "Intel I340-T4 (82580)" rev 0x01: msi, address 00:90:fb:37:74:06
em9 at pci4 dev 0 function 1 "Intel I340-T4 (82580)" rev 0x01: msi, address 00:90:fb:37:74:07
em10 at pci4 dev 0 function 2 "Intel I340-T4 (82580)" rev 0x01: msi, address 00:90:fb:37:74:08
em11 at pci4 dev 0 function 3 "Intel I340-T4 (82580)" rev 0x01: msi, address 00:90:fb:37:74:09
"Intel Core Management" rev 0x11 at pci0 dev 8 function 0 not configured
"Intel Core Scratch" rev 0x11 at pci0 dev 8 function 1 not configured
"Intel Core Control" rev 0x11 at pci0 dev 8 function 2 not configured
"Intel Core Misc" rev 0x11 at pci0 dev 8 function 3 not configured
"Intel Core QPI Link" rev 0x11 at pci0 dev 16 function 0 not configured
"Intel Core QPI Routing" rev 0x11 at pci0 dev 16 function 1 not configured
ehci0 at pci0 dev 29 function 0 "Intel 3400 USB" rev 0x05: apic 8 int 23
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 "Intel EHCI root hub" rev 2.00/1.00 addr 1
ppb4 at pci0 dev 30 function 0 "Intel 82801BA Hub-to-PCI" rev 0xa5
pci5 at ppb4 bus 5
pciide0 at pci5 dev 1 function 0 "ITExpress IT8213F" rev 0x00: DMA (unsupported), channel 0 wired to native-PCI, channel 1 wired to native-PCI
pciide0: using apic 8 int 16 for native-PCI interrupt
wd0 at pciide0 channel 0 drive 0: <TRANSCEND>
wd0: 1-sector PIO, LBA, 485MB, 994896 sectors
pciide0: channel 1 ignored (not responding; disabled or no drives?)
vga1 at pci5 dev 2 function 0 "ASPEED Technology AST2000" rev 0x10
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
pcib0 at pci0 dev 31 function 0 "Intel 3420 LPC" rev 0x05
pciide1 at pci0 dev 31 function 2 "Intel 3400 SATA" rev 0x05: DMA, channel 0 configured to native-PCI, channel 1 configured to native-PCI
pciide1: using apic 8 int 19 for native-PCI interrupt
wd1 at pciide1 channel 0 drive 0: <WDC WD2503ABYX-01WERA0>
wd1: 16-sector PIO, LBA48, 239429MB, 490350672 sectors
wd1(pciide1:0:0): using PIO mode 4, Ultra-DMA mode 6
ichiic0 at pci0 dev 31 function 3 "Intel 3400 SMBus" rev 0x05: apic 8 int 18
iic0 at ichiic0
iic0: skipping sensors to avoid ipmi0 interactions
spdmem0 at iic0 addr 0x50: 2GB DDR3 SDRAM PC3-10600
spdmem1 at iic0 addr 0x51: 2GB DDR3 SDRAM PC3-10600
pciide2 at pci0 dev 31 function 5 "Intel 3400 SATA" rev 0x05: DMA, channel 0 wired to native-PCI, channel 1 wired to native-PCI
pciide2: using apic 8 int 19 for native-PCI interrupt
isa0 at pcib0
isadma0 at isa0
com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
com1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo
pckbc0 at isa0 port 0x60/5
pckbd0 at pckbc0 (kbd slot)
pckbc0: using irq 1 for kbd slot
wskbd0 at pckbd0: console keyboard, using wsdisplay0
pcppi0 at isa0 port 0x61
spkr0 at pcppi0
wbsio0 at isa0 port 0x2e/2: W83627DHG rev 0x25
lm1 at wbsio0 port 0xa10/8: W83627DHG
mtrr: Pentium Pro MTRR support
uhub1 at uhub0 port 1 "Intel Rate Matching Hub" rev 2.00/0.00 addr 2
uhidev0 at uhub1 port 1 configuration 1 interface 0 "Holtek product 0x1400" rev 1.10/1.43 addr 3
uhidev0: iclass 3/1
ukbd0 at uhidev0: 8 modifier keys, 6 key codes
wskbd1 at ukbd0 mux 1
wskbd1: connecting to wsdisplay0
uhidev1 at uhub1 port 1 configuration 1 interface 1 "Holtek product 0x1400" rev 1.10/1.43 addr 3
uhidev1: iclass 3/1, 3 report ids
ums0 at uhidev1 reportid 1: 5 buttons, Z dir
wsmouse0 at ums0 mux 0
uhid0 at uhidev1 reportid 2: input=3, output=0, feature=0
uhid1 at uhidev1 reportid 3: input=1, output=0, feature=0
uhidev2 at uhub1 port 5 configuration 1 interface 0 "Avocent USB Composite Device-0" rev 2.00/0.00 addr 4
uhidev2: iclass 3/1
ukbd1 at uhidev2: 8 modifier keys, 6 key codes
wskbd2 at ukbd1 mux 1
wskbd2: connecting to wsdisplay0
uhidev3 at uhub1 port 5 configuration 1 interface 1 "Avocent USB Composite Device-0" rev 2.00/0.00 addr 4
uhidev3: iclass 3/1
ums1 at uhidev3: 3 buttons, Z dir
wsmouse1 at ums1 mux 0
uhidev4 at uhub1 port 5 configuration 1 interface 2 "Avocent USB Composite Device-0" rev 2.00/0.00 addr 4
uhidev4: iclass 3/1
ums2 at uhidev4: 3 buttons, Z dir
wsmouse2 at ums2 mux 0
vscsi0 at root
scsibus0 at vscsi0: 256 targets
softraid0 at root
scsibus1 at softraid0: 256 targets
root on wd1a (31bddb7bcd4537e3.a) swap on wd1b dump on wd1b
15:38:45 Wed Jun 13

holger

 

[jmt]

Dem ist leider nicht so. Es arbeitet immer nur ein Thread im Kernel (Big-Kernel-Log). Alle anderen Threads warten, wenn sie in den Kernel wollen. Im Userland laufen sie alle parallel. Deshalb sind die Auswirkungen auch nicht ganz so wild, wie es am Anfang klingt.

 

[mark05]

Dem ist leider nicht so. Es arbeitet immer nur ein Thread im Kernel (Big-Kernel-Log). Alle anderen Threads warten, wenn sie in den Kernel wollen. Im Userland laufen sie alle parallel. Deshalb sind die Auswirkungen auch nicht ganz so wild, wie es am Anfang klingt.

frei nach dem motto "taktrate ist durch nix zu ersetzen als noch mehr taktrate"

das der smp bereich nicht sondelich gut ist bei openbsd ist mir
klar aber fuer was wo fuer ich openbsd brauche reicht es alle male.

holger

 

[ChaosKind]

kann es sein, das ihr leicht vom Thema abweicht, hier geht es eher um Bitrig ...

ansonsten @mark05: für mich klingt es so als ob du der einzige Anwendungsfall sein sollst, für oBSD (nicht persönlich nehmen!)
Ich selbst mag BSD, und würde es auch durch aus gern als HOST System für VMs machen, weil es so mordsstabil und vor allem sicher ist, als Router hab ich auch schon ab und an bei multicore/multiprozessorhardware aber mit sehr schwachen CPUs (steinalt System) soo flaschenhälse gesehen im SMP, es verbrät halt nicht jeder gern ein nagelneuen i7-3770 nur um einen einzigen Kern zu nutzen.. und die performance im >GBit Bereich zu haben.

ich persönlich vermisse an oBSD Virtualisierung/Kernelmodule (geht quasi mit einher meiner Meinung nach) und SMP

Nebenbei heutzutage stellen sich auch immer weniger Leute eine Büchse mit oBSD als Router hin, meist bieten das die Switche/Fabrics auch so an oder es kommt halt ne Cisco Box hin und dann lüppt der mist... von daher verliert oBSD so auch immer mehr Nutzerbasis auf natürlichem wege, und damit es nich obsolete wird, sollte es sich auch neue Märkte erschliessen, bzw. dort einfach nur weitermachen.

 

[Yamagi]

Da habe ich ja was angerichtet... Ich hatte nie vor eine Grundsatzdiskussion über "OpenBSD und sein SMP" zu starten. Aber da es nun so gekommen ist... Das "Problem" (ob es nun eines ist oder nicht, mag jeder für sich selbst entscheiden) besteht darin, dass es als einzige Lockstruktur im Kernel den globalen Lock (unter FreeBSD GIANT, daher meist bei anderen BSDs auch so genannt) gibt. Das bedeutet erst einmal nur, dass im Kernel kaum Paralälität stattfinden kann, denn immer wenn ein Thread eine exklusive Operation durchfühen will, kommt alles zum Stehen. Und in den BSDs sind die meisten Operationen exklusiv. Dadurch ist der Kernel effektiv auf eine CPU begrenzt. Das schlägt auf das Userland durch. Zwar können im Userland die Prozesse beliebig viele Threads haben und beliebig viele Prozessoren nutzen, aber da viele Userland-Operationen und Syscalls sowieso Operationen im Kernel nach sich ziehen, wird der Kernel zum Flaschenhals. In der Praxis kommen daher auch Userlandanwendungen effektiv kaum über 1 bis 2 tatsächlich genutzte CPUs hinaus. Als Lösung kann man entweder den globalen Lock im Kernel durch Ressourcenlocks ersetzen, die nur die Teile blockieren, die tatsächlich gesperrt werden müssen. Das hat FreeBSD getan. Man kann aber auch den globalen Lock nur aus zentralen Stellen entfernen und ansonsten versuchen die exklusiven Operationen und damit die Anzahl der notwendigen Locks zu reduzieren. Das machen Linux und grob gesagt auch NetBSD. Welcher Ansatz nun besser ist, wird jeder anders beantworten...
Meine ganz persönliche Meinung ist nun, dass sich an der Frage "SMP" für jedes System sein Überleben oder Untergang entscheiden wird. Vielleicht nicht heute, aber morgen oder übermorgen. 2004 hatten alle Computer einen Prozessor, SMP-Systeme waren das Heu im Stecknadelhaufen. 2006 hatten sich die Dualcores durchgesetzt, 2010 die Quadcores. Inzwischen sind 8 logische Prozessoren "Standard". Bei Smartphones misst man an Anzahl der Kerne, statt in Megahertzen... Wir stehen noch ganz am Anfang der "Multicore-Ära", statt am Takt zu drehen, baut man in die Breite. Derzeit scheinen viele schwache Kerne als Alternativkonzept zu vielen starken Kernen aufzukommen. Wenn man das mal weiterdenkt, haben wir in 10 Jahren vielleicht 24 Kerne. Oder 128 ARM-Kerne. Was weiß ich. Aber sehr sicher nochmal deutlich mehr als heute. Das die Userland-Software vielleicht nie hinterherkommen wird, ist gut und schön. Aber dann möchte ich doch wenigstens viele Programme parallel ausführen können, ohne massive Performanceeinbrüche zu erleiden. Und da sind wir wieder beim Betriebssystem. Man mag argumentieren, dass OpenBSD kein gutes SMP braucht und heute mag es stimmen. Aber wird man in 10 Jahren auf seinem Router mit 16 Kernen auf die Leistung von ca. 14 verzichten wollen? Wird man in Zeiten von Stromspar-CPUs mit eher sinkender Leistung pro Kern überhaupt einen Prozessor bekommen, bei dem ein einzelner Kern zuverlässig 10Gbit/s filtern und routen kann? Das ist Zukunftsmusik, ja. Aber ich denke nicht so unrealistisch, dass man es einfach wegdiskutieren kann.
Um den Bogen zurückzuschlagen: Ich finde es dennoch gewagt, dass ein eher kleiner Fork gutes SMP in eine Jahrzehnte alte Codebasis einfügen will. Ohne kommerzielle Unterstützung dürfte das kaum machbar sein. Wenn ich die Featureliste von Bitring so lese, wäre die Energie besser in OpenBSD selbst oder in die Verbesserung von NetBSD oder FreeBSD investiert. Aber das sagte ich ja oben schon.

 

[ChaosKind]

Yamagi: FACK (:

mit einer Ausnahme, die ersten SMP Systeme gab es mit P3/Tualatin schon 2000 rum (;

 

[mark05]

hi

also die kisten die ich hier betreue haben mit bandbreiten deutlich > 1 GBit
und die cpu takten noch nicht mal hoch .

so wie @yamagi es erklaert hat so habe ich es auch im kopf was das smp bei openbsd betrifft.

jedoch brauche ich fuer packet forwarding oder packet routing kein smp .

einzig und alleine das board design , das netzwerk interface / chip und irq handling
ist enscheiden.

die cores kann ich dann immer noch mit proxys fuettern.
aber solange openbsd die aufbaben so gut und sauber erledigt wie ich es , bis heute ,
kenne sollange sehe ich keinen grund eine fork zu verwenden oder etwas anders .

was den fork betrifft , finde ich es schade das sich das wieder ein paar leute eine eingene
suppe kochen.

sie sollten leiber ihr koennen und zeit ind das verbessern vom z.b. openbsd smp
stecken., ergo pflichte ich das yamagi bei.


oder , was ich mir wuenschen wuerde , ein etwas modereneren FS wobei es hier
ja ggf licht am tunnel zu sehen ist,

leider sind die resourcen von openbsd begrenzt was kohle und human power betrifft,
und von daher finde ich es gut das , wenn , man was macht es richtig macht.

z.b. sollte man sich man die letzen anederungen im kernel anschauen .
stichwort "scsi io vscsi".

es geht halt alles nicht so schneller , und wuerde schneller gehen wenn man mit macht
anstatt was eigenes zu forken.

und so wie ich hening und ingo kennen gelernt habe schein das ein witziger haufen
von koennern zu sein .

holger

 

[darktrym]

Ein Problem wird auch Theo sein, weshalb das Forken und Austesten was möglich und sinnvoll ist doch ganz begrüße. Gut möglich, dass man Theo so schneller überzeugen kann.
Ich hoffe mal nicht, dass das Projekt ein MirBSD-Ende findet( wo ich mich immer frage ob qual. eine Verbesserung ist ).