FreeBSD 12 und uhidd

sterum

Well-Known Member
Ich verwende ja uhidd um die Multimediatasten meiner USB Tastatur anzusprechen und die Maus damit zu betreiben. uhidd verträgt sich ja nicht mit den Kernelmodulen die das System zur Verfügung stellt (ums.ko ukbd.ko uhid.ko) dehalb hab ich sie bisher immer in der /etc/devd/usb.conf auskommentiert. Seit FreeBSD 12 gibt es diese Datei aber nicht mehr, das Laden der USB Module wird wohl jetzt irgendwie anders gelöst.
Der uhidd kann zwar eigentlich die Kernelmodule mit dem Schalter -u entladen nur funktioniert das bei mir nicht und ums.ko bleibt bzw. wird dennoch geladen. So kommen sich die beiden Module uhidd.ko und ums.ko in die Quere und die Maus funktioniert nicht richtig, d.h. damit ein Mausklick ausgeführt wird muß ich sie zusätzlich bewegen.
Jetzt stellt sich halt die Frage wie man ab FreeBSD 12 das Laden der entsprechenden Module wieder verhindern kann.
 
Das Problem ist ja das in diese Datei keine Einträge erstellt werden müssen um das Laden zu verhindern sondern Einträge entfernt werden müssen. Einträge aus einer nicht vorhandenen Datei entfernen ist halt schwierig :)
 
Meine Theorie dazu ist ja, dass man den ganzen Kram aus der usb.conf einfach zum default gemacht hat und wenn man davon abweichen will eben dann einen eigenen Eintrag macht. Gibts ein match, dann wird halt der Default-Eintrag überschrieben.
 
Hab grad was im Netz gefunden.
Seit 12 kann man das Laden der Module über die rc.conf verhindern.
Code:
devmatch_blacklist="" # List of modules (w/o .ko) to exclude from devmatch.
 
Coole Sache.
Wundert mich aber, dass es nirgends dokumentiert scheint. Das einzige, was ich gefunden habe war das blacklisten via loader.conf (module_blacklist).
 
Das devmatch Framework ist auch noch sehr blutig und umfasst derzeit noch nicht alle Kernelsubsysteme. Daher wurde 12.0 auch noch mit dem GENERIC Kernel ausgeliefert und der MINIMAL Kernel blieb optional.
 
Okay, das war vorhin etwas kurz: devmatch ist im Prinzip die gleiche Funktionalität, die Linux erst mit udev und nun mit systemd schon seit bestimmt 15 Jahren implementiert. Das System geht die Hardware durch, ermittelt die benötigten Kernelmodule und lädt sie automatisch. Damit kann man minimale Kernel ausliefern, die gerade genug für den Boot selbst enthalten und alles andere ohne Zutun des Nutzers dynamisch nachladen. Das Design ist allerdings komplett anders, man könnte sagen (und sich dann drüber streiten), dass devmatch mehr der Unix-Philosophie folgt und die beinahe einfachst mögliche Lösung darstellt.
 
Okay, das war vorhin etwas kurz
Nö. Gar nicht. Also jedenfalls nicht für mich. Mit dem Stichwort devmatch habe ich obige Seite gefunden, die das eigentlich gut umreißt.
Trotzdem Danke für Deinen informativen Nachtrag.

Das Design ist allerdings komplett anders, man könnte sagen (und sich dann drüber streiten), dass devmatch mehr der Unix-Philosophie folgt und die beinahe einfachst mögliche Lösung darstellt.
Könnte man sagen. Ich finde die Umsetzung jedenfalls ganz gut.
 
Zurück
Oben