NetBSD 7.0 - Release-Thread

darktrym

darktrym

Fahnenträger
Lang hats gedauert nun ist es endlich Realität, ein neues Release ist draußen. Datiert auf den 25. September, Bekanntgabe aber erst heute den 8. Oktober. Ein Auszug der Features:


  • DRM/KMS support brings accelerated graphics to x86 systems using modern Intel and Radeon devices.
  • Multiprocessor ARM support.
  • Support for many new ARM boards:
    • Raspberry Pi 2
    • ODROID-C1
    • BeagleBoard, BeagleBone, BeagleBone Black
    • MiraBox
    • Allwinner A20, A31: Cubieboard2, Cubietruck, Banana Pi, etc.
    • Freescale i.MX50, i.MX51: Kobo Touch, Netwalker
    • Xilinx Zynq: Parallella, ZedBoard
  • Major NPF improvements:
    • BPF with just-in-time (JIT) compilation by default
    • support for dynamic rules
    • support for static (stateless) NAT
    • support for IPv6-to-IPv6 Network Prefix Translation (NPTv6) as per RFC 6296
    • support for CDB based tables (uses perfect hashing and guarantees lock-free O(1) lookups)
  • Multiprocessor support in the USB subsystem.
  • blacklistd(8), a new daemon that integrates with packet filters to dynamically protect other network daemons such as ssh, named, and ftpd from network break-in attempts.
  • Numerous improvements in the handling of disk wedges (see dkctl(8) for information about wedges).
  • GPT support in sysinst via the extended partitioning menu.
  • Lua kernel scripting.
  • epoc32, a new port which supports Psion EPOC PDAs.
  • GCC 4.8.4, which brings support for C++11
  • Optional fully BSD-licensed C/C++ runtime env: compiler_rt, libc++, libcxxrt.

Zusammengefasst, viel, sehr viel Arbeit wurde in den Support von dutzenden ARM-(Evaluation)-Boards gesteckt, Kudo Nipppon, einige haben sogar SMP Unterstützung wie der Raspberry Pi 2. Ein Major-Update des Grafikstacks(Stand Linux 3.15) als Wrapper gelöst und NetBSD gibts als llvm/clang-Build.
Weitere Fokusierungen werden folgen, SMP des Netzwerk-Stacks, Ausmisten des Kernels, Ausbau des DTrace-Support.
 
Weiß jemand, ob das Lua Kernel Scripting schon zu nennenswerten Projekten geführt hat? Das Release ist ja neu, aber der Code selbst existiert glaube ich schon ein Weilchen. Ist ja ziemlich interessant. Vielleicht findet ja jemand mal ein Killerfeature dafür. :)
 
Da gibt es ein paar Slides:

https://archive.fosdem.org/2013/sch..._netbsd_kernel/slides/278/kernel_mode_lua.pdf

Da wird genannt:
  • Rapid Application Development" approach to driver/kernel development
  • Modifying the system behaviour
  • Conguration of kernel subsystems
Kurzum, um Skripten zu können. ;)

Ich glaube das ist mehr ein Research Ding, als irgendwas. Aber ich denke, dass wenn man mal schnell was aufziehen/testen will und man sich mit nur-Userland schwer tut. Ein anderer Punkt könnte die Lehre sein. Also wenn man sich dem Kernel vorsichtig nähern will.

Aber konkrete Idee habe ich keine, was natürlich nicht unbedingt heißt, dass es unnötig ist. In der IT gab es schon häufiger Sachen, die mitunter auch Jahrzehnte rumgammeln, bis da ein Killerfeature kommt und sich alle fragen warum da nicht schon früher jemand drauf kam.

Wie gesagt, war glaube ich mal mehr ein Proof of Concept von der Idee "Skriptsprache im Kernel". So wir Skriptsprachen in allem möglichen andern (IRC Clients, Datenbanken, Window Managern, etc.). Aber vielleicht kommt ja jemand auf eine geniale Idee, einfach nur weil es das gibt. Wie gesagt, wäre nicht das erste Mal, dass so etwas passiert.
 
Dieser heiße Scheiß ist auch im Linux Kernel enthalten und nennt sich da eBPF, so sinnfrei kann dann die Idee eigentlich nicht sein.
 
Hmmm, ich habe den Eindruck dass da etwas in die falsche Richtung läuft. Auf der einen Seite gibt es gute Gründe den Kernel möglichst klein zu halten und alles was irgend möglich ist in den Userspace auszulagern, auf der anderen Seite packt man eine dynamische Sprache in den Kernel was sicherlich dessen Weiterentwicklung vereinfacht aber letztlich wohl seine Komplexität erhöht, - um von Nachteilen was Laufzeit und Recourcen angeht erst garnicht zu reden. Was m.E. von einem Kernel zu erwarten ist, ist in erster Linie Stabilität und Effizens, und nicht Anpassbarkeit an alle nur möglichen Wünsche. Prototyping und Instrumentation ist eine Sache, wenn aber erst einmal einige hundert Scripte im Kernel versammelt sind, dürfte es kaum noch einen Weg zurück geben.

Ich denke man zäumt da das Pferd vom Schwanz her auf...

Nachtrag: Ich hätte nichts dagegen wenn Lua die unsäglichen Shell-Scripte und auch das omnipresente Python ersetzen würde, aber das ist eine ganz andere Baustelle.
 
Mal unter uns Sachen mit "aber der Kernel wird damit größer" zu begründen sind ein wenig komisch. Schließlich nutzt hier keiner einen Microkernel und Entwicklungen wie KMS oder die ganzen Dateisystemen im Kernel sind auch nicht ganz ohne. Richtig ist wenn das in den Kernel Einzug hält, sollten wenigstens genug Schnittstellen abgedeckt werden, damit man es für was sinnvolles verwenden kann am besten mit Beispielcode. Eine kurze Suche ergab lausige zwei Beispielskripte für Lua im Kernel(sqlite und gpio), ich müsste mal im Kernel Source nach lua grepen.
 
darktrym schrieb:
Mal unter uns Sachen mit "aber der Kernel wird damit größer" zu begründen sind ein wenig komisch. Schließlich nutzt hier keiner einen Microkernel ...
Zum Vergrößern anklicken....
Ich benutze auch Windows und fahre VW, also daraus kann man kein Argument für einen "großen Kernel" gewinnen. Gerade die BSDs demonstrieren doch dass das Betriebssystem weit mehr ist als nur der Kernel und wichtige Bestandteile wie z.B. die Shells sehr gut außerhalb untergebracht sind.
... und Entwicklungen wie KMS oder die ganzen Dateisystemen im Kernel sind auch nicht ganz ohne.
Zum Vergrößern anklicken....
Eben! Aber das heißt ja nicht dass man diese Entwicklung für richtig halten muss.

Nachtrag: eBPF ist wohl eine etwas andere Sache, keine vollständige Skriptsprache. Aber wenn ich das richtig lese (?) bringen die sogar einen JIT Compiler im Kernel unter.
 
Es ist eben immer eine Abwägung: Man will etwas oder nicht.

Lua ist jetzt nicht das riesen Monster und vor allem die Integration als Skriptsprache als Teil von anderen Systemen und der relativ niedrige Aufwand (natürlich nie null, aber eben *relativ* niedrig) sind wohl die Stärken davon. Das heißt nicht, dass man alles auch machen soll, was man machen kann, aber ich glaube man muss der Sache einfach auch irgendwo Zeit einräumen um sie zu bewerten. Im schlimmsten Fall macht ein Kernelfeature Probleme, hat kaum Verwendung und fliegt raus. Das nennt man auch Research. Ist ja nicht so als hätte NetBSD einen großen Plan alles auf Lua umzuschreiben und einen Lock-In zu machen.

Habe mir den Code noch nicht angesehen (aber es vor und deshalb auch die ursprüngliche Frage), aber ich gehe mal davon aus, dass das soweit möglich relativ eigenständig gehalten wurde.

Will übrigens nicht die Diskussion nur auf das Thema lenken. NetBSD 7 ist ein ziemlich cooles Release mit vielen interessanten Verbesserungen. Bin ja ein Fan von so Minifeatures, die einfach ein Problem, das man immer wieder im normalen täglichen Betrieb hat angehen. Bei den BSDs gibt's da immer schöne kleine Lösungen, die keine Overkills sind. Da fällt mir, weil ich es kürzlich verwendet habe daemon(8) unter FreeBSD ein und oben in der Changelog der blacklistd(8). Da man man vielleicht meinen das ist jetzt die Xte Version, aber ganz ehrlich. Viele von den Alternativen sind ziemlich komplex und groß und passen nicht, machen zu viel oder zu wenig.
 
Athaba schrieb:
Das heißt nicht, dass man alles auch machen soll, was man machen kann, aber ich glaube man muss der Sache einfach auch irgendwo Zeit einräumen um sie zu bewerten.
Zum Vergrößern anklicken....
Klar, so kann man das sehen. Aber man kann das auch auf einer abstrakteren Ebene diskutieren, auf der des Designs des OS.
NetBSD 7 ist ein ziemlich cooles Release mit vielen interessanten Verbesserungen.
Zum Vergrößern anklicken....
Das glaube ich gerne und soll von mit nicht in Frage gestellt werden!
 
Also die Libs liegen in /usr/lib/lua/5.3 und sind recht überschaubar:
gpio, sqlite, syslog

Kein Wunder das ich den Kram im Kernel nicht gefunden hab, liegt ja im Userland. Das Lua-Modul wird ja von Hause aus nicht geladen. Den Sinn hinter luactl ist mir noch nicht klar. Nach dem Laden kann man via Device kommunizieren.
 
darktrym schrieb:
Kein Wunder das ich den Kram im Kernel nicht gefunden hab, liegt ja im Userland. Das Lua-Modul wird ja von Hause aus nicht geladen. Den Sinn hinter luactl ist mir noch nicht klar.
Zum Vergrößern anklicken....
Wenn ich die Slides S.34-36 richtig verstehe läuft das wohl in etwa so dass Lua mit sysctl(8) aktiviert wird, der Treiber mit ioctl(8) initialisiert wird und dann im Kernel mit luactl(8) aufgerufen wird. Der started einen LuaState der dann die Lua module im userspace aufruft. Der Punkt dürfte sein dass natürlich das Lua im Kernel entsprechend angepaßt ist, also die Sprache schon unmodifiziert ist, aber das Laufzeitsystem sinnvollerweise nicht alles darf (s.a. Slides S.25).

Müßte man mal ein wenig mit spielen und einiges ausprobieren. Dürfte nicht allzu schwierig sein. Schade dass ich kein NetBSD zur Verfügung habe...

Referenzen:
http://man.netbsd.org/7.0/usr/share/man/html8/luactl.html
http://man.netbsd.org/7.0/usr/share/man/html9/ioctl.html
 
Nun ja für mein Verständnis brauchts da überall Schnittstellen zur Lua VM damit Lua-Programme mit den Kernelsubsystemen interagieren können. Entweder sind meine Shell-Künste eingerostet nur gerade das finde ich nicht. Kannst ja mal selbst die syssrc.tgz entpacken und nach lua grepen.
 
Ich meine dass luactl(8) die Schnittstelle ist:
Code: 
> luactl create test
> luactl require test  test
"test" ist der Name des LuaStates im Kernel und "test.lua" der des Lua moduls im Userspace. Es ist die Frage ob man sich im Modul mit print() alles Mögliche ausgeben kann.

Na ja, ohne es auszuprobieren bleibt das alles Vermutung ...
 
Ich glaub' wir reden hier massiv aneinander vorbei oder mind. einer steht hier auf dem Schlauch. Die Lua-VM soll es dir doch erlauben Dinge im Kernel zu tun, die man sonst nur mit C(Kompilierierung), im Kernel erledigen könnte bspw. Treibergeschichten via Lua im Userland. Dafür ist es aber zwingend notwendig, dass die Schnittstellen der Subsysteme für Lua geöffnet werden, d.h. Push und Pop der Werte vom Kernel in die VM mit Typumwandlungen damit Lua-Userlandskripte damit was anfangen wissen(und andersrum). Genau deshalb gibts diese luactl um den State zu kontrollieren.
Diese Skripte(/usr/share/examples/lua) sollen das demonstrieren das man Systemschnittstellen verwenden kann, eigentlich sind die Binding für den NetBSD Kernel unter /usr/lib/lua/5.3(7.99.21). Nur die Schnittstellen sind doch völlig unterinteressant.
Dinge wie Zugriff auf die Sensoren, Energieverwaltung, Netzwerk, VFS wären wesentlich interessanter zum rumspielen als Dinge wofür es bereits Device-Knoten gibt.
 
darktrym schrieb:
Ich glaub' wir reden hier massiv aneinander vorbei oder mind. einer steht hier auf dem Schlauch.
Zum Vergrößern anklicken....
Kann gut sein. Der auf dem Schlauch steht und wilde Vermutungen anstellt bin wohl eher ich. Ich habe ja kein NetBSD zur Verfügung und in den Manual Seiten fehlen leider Beispiele.
Die Lua-VM soll es dir doch erlauben Dinge im Kernel zu tun, die man sonst nur mit C(Kompilierierung), im Kernel erledigen könnte bspw. Treibergeschichten via Lua im Userland.
Zum Vergrößern anklicken....
Klar, ich würde da nur so vorgehen dass ich zunächst einmal etwas zum laufen bringe um zu sehen wir die LuaVM im Kernel arbeitet und dann weiter sehen. YMMV
Dafür ist es aber zwingend notwendig, dass die Schnittstellen der Subsysteme für Lua geöffnet werden, d.h. [...] Dinge wie Zugriff auf die Sensoren, Energieverwaltung, Netzwerk, VFS wären wesentlich interessanter zum rumspielen als Dinge wofür es bereits Device-Knoten gibt.
Zum Vergrößern anklicken....
Sehe ich auch so: Werf mal einen Blick auf ioctrl(8) und lua(4). Da muss man sich halt reinfummeln oder in einer der Mailing Listen fragen (Lua, NetBSD). Marc Balmer ist wenn ich mich recht erinnere auf der Lua-Users Mailing Liste aktiv.
 
Werd ich sicherlich mal tun, nachdem ich darin rumgebohrt hab. Ich kenn' einige Kommentare seitens der Community die ebenfalls eher ablehnend waren. Es war ja auch mal angedacht sysinst mittels Lua aufzubohren.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben