Hallo Thomas,
auch noch mal danke für die ausfühliche Erläuterung des default-Handling Problems - ich werde das mit den zuständigen Kollegen diskutieren. Kannst Du Dir erklären, weshalb bisher noch kein anderer User darüber 'gestolpert' ist? Um einen prinzipiellen Showstopper kann es sich wohl nicht handeln.
Gruß & Gute Gesundheit
Frank
Einige Fragen zu Virtuellen Devices / RAP files
Re: Einige Fragen zu Virtuellen Devices / RAP files
Hallo Frank,
Ein prinzipieller Showstopper ist es vielleicht nicht, aber ich bin auch nicht gerade der erste User der über diese Themen stolpert, siehe:
Mai 2018 , März 2018 , Oktober 2017 , Oktober 2017 , August 2017
Aus den Kommentaren heraus kann ich lesen, dass meine Vorgänger schliesslich vom daemon aus die defaults initialisiert haben. Dazu mussten zusätzlich noch die *.RAP Dateien geparst werden und zur config.rsc gemappt werden, nur um an den eigentlichen Datentyp der variable zu kommen. Ein ziemlicher Aufwand, und noch dazu etwas, was jeder virtuelle Device daemon neu implementieren müsste. Hinzu kommt die Frage, wie man im daemon überhaupt sauber einen Reset erkennen kann um dann die defaults neu zu schreiben.
Aus meiner Sicht eine besser Lösung:
- PiCtory anpassen um den Datentypen mit in die config.rsc zu exportieren.
- piControl Kernel Treiber default handling vom Datentypen abhängig machen, und dann um neue Datentypen erweitern (z.B. STRING wäre relativ einfach möglich) Die Schwierigkeit bei diesen Ansatz entsteht beim REAL Datentyp: Im Kernelspace darf man die FPU nicht benutzen, und ohne FPU wird es schwieriger (aber nicht unmöglich) den String in eine IEEE 754 Repräsentation umzuwandeln.
Daher könnte auch dieser Ansatz interessant sein:
- PiCtory anpassen um den Datentypen mit in die config.rsc zu exportieren.
- /usr/bin/piControlReset so anpassen, dass es beim Reset die config.rsc einliest und dann ein 4kb grosses Imagefile erstellt z.B. /etc/revpi/default.img, und erst danach den ioctl KB_RESET aufruft.
- piControl Kernel Treiber: so anpassen, dass die 4kb grossen Image Datei /etc/revpi/default.img beim KB_RESET 1:1 eingelesen wird um das prozessabbild zu initialisieren.
Damit wäre das Problem des Umwandelns vollständing im Userspace angekommen, wo die FPU und auch mächtige Funktionen wie atof() oder strtod() verfügbar sind, und es für die Community ungleich einfacher wird, wenn nötig weitere Datentypen beizusteuern. (=> Wäre das Design heute so, dann hättet ihr bereits einen Pullrequest für STRING,REAL und LREAL von mir erhalten)
Wie Ihr sehen könnt: Hier sind erst mal wichtige Software-Architektur-Entscheidungen zu treffen. Als Community-Mitglied kann ich im Moment hier genau gar nix machen, ausser hier im Forum weiter regelmässig zu nerven
Ein prinzipieller Showstopper ist es vielleicht nicht, aber ich bin auch nicht gerade der erste User der über diese Themen stolpert, siehe:
Mai 2018 , März 2018 , Oktober 2017 , Oktober 2017 , August 2017
Aus den Kommentaren heraus kann ich lesen, dass meine Vorgänger schliesslich vom daemon aus die defaults initialisiert haben. Dazu mussten zusätzlich noch die *.RAP Dateien geparst werden und zur config.rsc gemappt werden, nur um an den eigentlichen Datentyp der variable zu kommen. Ein ziemlicher Aufwand, und noch dazu etwas, was jeder virtuelle Device daemon neu implementieren müsste. Hinzu kommt die Frage, wie man im daemon überhaupt sauber einen Reset erkennen kann um dann die defaults neu zu schreiben.
Aus meiner Sicht eine besser Lösung:
- PiCtory anpassen um den Datentypen mit in die config.rsc zu exportieren.
- piControl Kernel Treiber default handling vom Datentypen abhängig machen, und dann um neue Datentypen erweitern (z.B. STRING wäre relativ einfach möglich) Die Schwierigkeit bei diesen Ansatz entsteht beim REAL Datentyp: Im Kernelspace darf man die FPU nicht benutzen, und ohne FPU wird es schwieriger (aber nicht unmöglich) den String in eine IEEE 754 Repräsentation umzuwandeln.
Daher könnte auch dieser Ansatz interessant sein:
- PiCtory anpassen um den Datentypen mit in die config.rsc zu exportieren.
- /usr/bin/piControlReset so anpassen, dass es beim Reset die config.rsc einliest und dann ein 4kb grosses Imagefile erstellt z.B. /etc/revpi/default.img, und erst danach den ioctl KB_RESET aufruft.
- piControl Kernel Treiber: so anpassen, dass die 4kb grossen Image Datei /etc/revpi/default.img beim KB_RESET 1:1 eingelesen wird um das prozessabbild zu initialisieren.
Damit wäre das Problem des Umwandelns vollständing im Userspace angekommen, wo die FPU und auch mächtige Funktionen wie atof() oder strtod() verfügbar sind, und es für die Community ungleich einfacher wird, wenn nötig weitere Datentypen beizusteuern. (=> Wäre das Design heute so, dann hättet ihr bereits einen Pullrequest für STRING,REAL und LREAL von mir erhalten)
Wie Ihr sehen könnt: Hier sind erst mal wichtige Software-Architektur-Entscheidungen zu treffen. Als Community-Mitglied kann ich im Moment hier genau gar nix machen, ausser hier im Forum weiter regelmässig zu nerven
Re: Einige Fragen zu Virtuellen Devices / RAP files
Hi Thomas,
das Feature Callbacks statt Polling zu nutzen ist ein Thema, das wir auf dem Radar haben, siehe hier:
https://revolution.kunbus.de/forum/view ... 7228#p7228
das Feature Callbacks statt Polling zu nutzen ist ein Thema, das wir auf dem Radar haben, siehe hier:
https://revolution.kunbus.de/forum/view ... 7228#p7228
Re: Einige Fragen zu Virtuellen Devices / RAP files
Hallo Thomas,
hab Dir per PM einen Workaround für das 'fehlender Datentyp in der RSC-Datei' Problem zur Verfügung gestellt. Bitte um kurzes Feedback, ob das so für Dich brauchbar ist; dann können wir ggf. entscheiden ob diese Änderung Teil einer zukünftigen Release wird.
Gruß
Frank
hab Dir per PM einen Workaround für das 'fehlender Datentyp in der RSC-Datei' Problem zur Verfügung gestellt. Bitte um kurzes Feedback, ob das so für Dich brauchbar ist; dann können wir ggf. entscheiden ob diese Änderung Teil einer zukünftigen Release wird.
Gruß
Frank
