Einige Fragen zu Subsystemen des freeBSD Kernels.

[das.chaos]

Moin,

ich bin etwas am "Experimentieren" bzw. dabei mir den
Kernel (sowohl als auch Komponenten des Userspace)
des FreeBSD 11-RELEASES fuer die Integration in
Eingebetteten Systeme anzupassen, die sowohl MIPS
als auch ARM basierende SoC integrieren.

Im Kontext von Eingebetteter Systemen sind Ressourcen
wie bspw. Kapazitaet von Speichermedien (fluechtig sowie
nicht-fluechtig) sowie die Kapazitaet von in SoC integrierter
CPU (bspw. QCA955X Serie) nach Loriot von ubersichtlicher
Groesze bzw. (im Kontext von MIPS sehr) knapp bemessen.

Nachdem ich testweise das jail(4) Subsystem im Kernel
entfernte (der Aufwand war Minimal und ich habe bei der
deduktiven Herangehensweise viel bzgl. OS Design im
Kontext des Unix Konzeptes gelernt). Hintergrund dieser
Teiloperation ist, dass ich Isolation von logischen Prozessen
bzw. einer Gruppe von einander abhaengigen Prozessen
im Kontext von bspw. erwaehnten SoC durchaus per
capsicum(4) bzw. casperd(8) realisierbar ist, da bspw.
im besagten SoC (bzgl. von Use-case derartiger SoC)
eine sowie mehree abgeleitete Jail(4) instanzen ein
"overkill" ist.



Bspw. habe ich alle die vom Kernel unterstuetzten Dateisysteme mal abgesehen von

• autofs(4)
• deadfs(4)
• devfs(4)
• fdescfs(4)
• ffs(4)
• fifofs(4)
• msdosfs(4) *brrr*
• nandfs(4)
• nfs(4)
• procfs(4)
• pseudofs(4)
• tmpfs(4)
• ufs(4)

aus Code-base rausgekantet, wobei eine Teilmenge
von geom(4) Klassen im Kontext des Use-case von
erwaehnten SoC genutzt wird, bspw. geom_map(4).

Um weiteren Platzbedarf fur Prozesse im Userspace
bzw. den Ressourcenbedarf des Kernels (sowie im
Userspace abhaengiger Komponenten) zu mindern,
stelle ich mir folgende Fragen:

1. Macht das Entfernen von netmap(4) im Kontext von MIPS / ARM basierten SoC Sinn (mir ist bewusst dass netmap(4) shon jetzt optional ist, aber ich will die Code-base minimieren, denn bzgl. ifnet(9) ist schon ein gewisser "Impact" zu beobachten)?
2. Sollte vnet(4) in diesem Kontext "entfernt" bzw. die Makros von diesen gekapselten Attributen ersetzt werden werden (was signifikant den Ressourcenbedarf des Kernels minimiert)?
3. Oder anders gefragt: ist VIMAGE in Code-base fuer MIPS (oder auch ARM) basierten SoC sinnvoll, wenn es sich der Use-case des OS entweder fuer "plaste-router-boards" oder fuer Mobile Stations (Mobiltelephon, etc. ...) definiert waere?
4. Sollte dtrace(4) Subsystem entfernt werden oder anders geftragt: existiert fuer dtrace(4) ein Use-case im Kontext von Mobile Stations?
5. Wuerde cuse(4) bzw. das Darstellen von Character Devices in Userspace ein Use-Case bzgl. dem Deployment von Software im Kontext von Mobile Stations darstellen?

Diese Fragen koennte ich auch mir selbst beantworten,
aber die Sichtweisen der im Forum anwesenden bzw.
versammelten Menschen ist mir wichtig bzw. sind mir
eine Inspirationsquelle.

 

[Crest]

Also gerade die Jails würde ich in Embedded Systems behalten, weil sie kaum Resourcen fressen und sehr gute Isolation ermöglichen. Eine Jail muss kein (eigenes) vollständiges Userland haben. Ein statisches Binary kann man ruhig in ein leeres Verzeichnis sperren. Dynamisch gelinkte Binaries brauchen halt den Runtime Linker und ihre shared Libraries. Skripte brauchen ihren Interpreter usw. Damit kann man ein kleines System sehr gut härten. Dazu kommt das sich Resourcen mit rctl auch gut auf Jails verteilen lassen.

 

[das.chaos]

Danke, dann werde ich jail(4) fuer Release re-integrieren!