ELV Journal 2/2018

Themen, die in keine andere Kategorie passen

Moderator: Co-Administratoren

Benutzeravatar
deimos
Beiträge: 5383
Registriert: 20.06.2017, 10:38
System: Alternative CCU (auf Basis OCCU)
Wohnort: Leimersheim
Hat sich bedankt: 121 Mal
Danksagung erhalten: 949 Mal
Kontaktdaten:

Re: ELV Journal 2/2018

Beitrag von deimos » 21.03.2018, 13:24

jmaus hat geschrieben:
deimos hat geschrieben:Und ich sehe auch eine Möglichkeit, wie man das ohne extra USB Treiber machen könnte (und ggf. auch ohne extra Treiber für die Funkmodule am GPIO), aber dafür müsste man ein paar Sachen am eq3_char_loop und am multimacd umbauen. Und da letzterer nicht OS ist, kann ich da halt nicht wirklich was dran machen.
Dann solltest du definitiv auf dem Usertreffen mich bzw. eQ3 dazu einmal ansprechen und wir können dann mal rausfinden wie die Chancen stehen das das irgendwann alles mal OS wird (rfd sicher nicht). Auf der anderen Seite muss man aber auch sagen, wenn es mit einem generischen USB Treiber wie mit dem HmIP-RFUSB aber geht dann sollte man das ggf. bevorzugen weil es dann ggf. allgemeingültiger ist und ausserhalb der eq3_char_loop/multimacd welt dann vllt. funktioniert.
deimos hat geschrieben: (Grundsätzlich könnte man natürlich auch den rfd in den hmserver integrieren und bräuchte dann überhaupt keine extra Sachen im Kernel mehr, aber das ist dürfte eine größere Operation werden)
Jetzt willst du auch noch den HmServer anfassen (Vorsicht: Java!) ? ;) Gerade aber für die Dinge die schützenswerte Interna beinhalten (z.B. rfd) wirst du meiner Erfahrung nach wenig Chancen haben die jemals als OS zu sehen weil eQ3 definitiv nicht ihr Interna der Funkübertragung preisgeben möchte. Für alles drumherum stehen die Chancen aber gut, würde ich sagen (wenn man es den ordentlich vorbringt und auch nicht patzig wird wenn die Antwort erst einmal 'nein' ist) :)
Nee, den hmserver will *ich* sicher nicht anfassen. Ich ergründe nur die (technischen) Möglichkeiten. Und da ist es so, dass ein physikalisches Gerät von zwei Prozessen gleichzeitig verwendet wird. Da gibt es grundsätzlich zwei Möglichkeiten: Einen Proxy zwischenrein, der den Zugriff zusammenführt und regelt (Stichwort mutlimacd) oder alle in einen Prozess ziehen (Stichwort alles in den hmserver).
Dass das beim HmIP-RFUSB einfach mit dem cp210x Treiber funktioniert, liegt ja einfach nur daran, dass da nur ein einziger Prozess Zugriff drauf braucht.

Wenn ich mir eine Lösung raussuchen könnte, dann würde ich den Weg über ein angepassten multimacd/eq3_char_loop gehen und zwar in der Form, dass der eq3_char_loop nur noch ein reiner Proxy ist mit einer 1:1 Kanal Beziehung zwischen Master (multimacd) und Slave (rfd bzw. hmserver) und der nur existiert, weil es schwierig ist, dev Nodes aus dem Userspace bereitzustellen und dem multimacd, welcher den Code für Locking und Priorisieren aus dem raw-Treibern eingebaut bekommt und dann direkt auf das jeweilige tty-Device geht. Das das Argument mit den Latenzen bei den tty Geräten nicht (mehr) gilt, hatte ich ja schon beschrieben.

Diese Lösung wäre überschaubar einfach zu implementieren und birgt deutlich weniger Fehlerpotential, als rfd und hmserver anzufassen.

Viele Grüße
Alex

Antworten

Zurück zu „OffTopic“