eibd(war bcusdk) Fork -> knxd

[Zepp]

Ich vermute, dass der Grund dafür ist, die C und C++ Version möglichst ähnlich zu halten. Mit dem expliziten "me" und structs die als ersten member die struct der Basisklasse enthalten wird in QP-C die Objektorientierung implementiert.

struct Baseclass {
   ...
}

struct Childclass {
   struct Baseclass super;
   ...
}

Baseclass_foo(struct Baseclass *me, params)
Childclass_foo(struct Childclass *me, params)

Childclass c;

Baseclass_foo((struct Baseclass *)&c, ...)

[Smurf]

Konkretes Beispiel: Objekte mit statischen Funktionen und "me" als erstem Parameter, statt normale Methoden mit implizitem "this".
Zeiger auf Methoden sind syntaktisch ein bisschen nervig, aber wirklich kein Hexenwerk.

Ich sehe mir das demnächst mal genauer an (und frage ggf. nach), aber erst wenn Sourceforge wieder funktioniert.

[Zepp]

Könntest du mal ein konkretes Beispiel nennen? Ich bin mir sicher, dass Herr Samek gute Gründe hatte das Framework genau so zu implementieren wie es ist.
Ich kenne nur die C Version und der Code ist mit der beste den ich jeh gesehen habe.

Wie ist deine Meinung zum eibd-code? Gefällt dir der besser?

[Smurf]

Ich habe mir mal den QP-C++-Code angesehen. Sagen wir mal so: Idiomatisches C++ sieht ein bisschen anders aus. :-/

Zu ihrer Ehrenrettung muss man dazusagen, dass QP aus dem Embedded-Bereich kommt und sich "idiomatisches C++" und "optimierter Code für embedded-Systeme" gegenseitig so'n bisschen ausschließen. Aber diese Erkenntnis hilft bei knxd nur bedingt was.

[Zepp]

Wenn eibd sowieso schon Aktoren nutzt, drängt es sich natürlich auf auch ein Aktor-framework einzusetzen. Es gibt übrigens auch QP-C++ (und einige andere Aktor Implementierungen für C++ die ich aber nicht kenne)

[Smurf]

Der in knxd verwendete C++-Anteil ist relativ überschaubar (keine Templates, kein Operator Overloading, etc.).

Die Semaphoren in pthsem werden eigentlich nur verwendet, um zu signalisieren, dass eine Queue nicht leer ist – was man wiederum nur deswegen braucht, weil der einzelne Aktor auf mehrere Events lauschen "muss" (meistens: eine Queue, ein Objekt dass der Task beendet werden soll, und einen Timeout o.Ä.) und die Queue-Abstraktion in pth(sem) keine Eventquelle ist. Das kann man um Einiges zielführender programmieren, d.h. jeder Aktor bekommt genau eine Queue und höchstens einen Timeout – und wenn man mehr braucht, will man eigentlich mehr als einen Aktor. :-P

QP-C sieht so aus, als könnte es genau dieses Modell perfekt unterstützen.

[Zepp]

Ich bin dafür leider vollkommen ungeeignet, da ich keine Ahnung von C++ habe. Ich setze das QP-C (ohne ++) framework schon einige Jahre im embedded-Bereich ein und bin davon sehr begeistert. Für die meisten Aufgaben ziehe ich QP jederzeit einem RTOS vor. Ob es auch für den eibd die richtige Wahl ist kann ich nicht beurteilen, der Umstieg auf ein event/actor/return-to-completion (RTC) Modell würde eventuell dazu führen, dass einiges umgebaut werden muss.

Ich kenne pthsem nicht, aber

"Pth (...) provides non-preemptive priority-based scheduling for multiple threads of execution"

könnte ein Hinweis darauf, sein, dass der Weg nicht soweit ist.

"pthsem is an extend version, with support for semaphores added."

eher ein Hinweis, dass dem nicht so ist.

[Smurf]

Sieht auf den ersten Blick nicht schlecht aus. Zepp: Du willst dir doch bestimmt diesen Rewrite auf die Fahnen schreiben ..?

[Zepp]

ein sehr schöne Möglichkeit für portable multithreaded Anwendungen ist das QP Aktor framework:

http://state-machine.com/win32/index.php
http://state-machine.com/linux/index.php

[Smurf]

Es muss halt jemand tun. Prinzipiell ist das pthreads-Rewrite der wichtigste Schritt, um da hinzukommen.
(Gibt es pthreads unter Windows, oder muss man das kapseln?)

Ein .INI-Parser statt der bzw. als Ergänzung zur Befehlszeile wäre auch gut.

Bis es das gibt, muss man wohl eine Linux-VM starten, oder einen RaspberryPi danebenhängen, und mit dem reden …

[l0wside]

Gibt es bei den ganzen anstehenden Änderungen denn die Perspektive, dass der knxd eines Tages unter Windows läuft?
Ich bin kein grenzenloser Windows-Anhänger, würde aber bei cross-platform-Projekten für KNX gerne ein einheitliches Interface verwenden können. Bisher gibt es unter Windows nur Falcon (unportabel, schlecht dokumentiert, in der Summe einfach furchtbar), Weinzierl kDrive (closed source, entweder kastriert oder kostenpflichtig, nur x86) und libknx (kann m.W. auch nur Multicast und ist auf IP-Interfaces beschränkt).

Ich würde mich drum kümmern, bin aber im Moment anderweitig geerdet: QVisu, Multisensor.

Max

[Smurf]

Und ein bisschen PHP, RPM und debian bauen, und was man sonst so braucht.

Fein.

https://github.com/knxd/knxd/wiki/ToDo

[JuergenS]

Überhaupt finde ich, es muss nicht sein dass ich aktuell alles komplett alleine mache. :-P

Hallo,

ich könnte ein bisschen Hilfe anbieten - sehr gute C++ und GNU/Linux Kenntnisse, Raspberry Pi fan, relative gute automake/autoconf Kenntnisse, praktische Erfahrungen mit dem Support von Public Domain Paketen. Und keine Angst vor Dokumentation (obwohl ich knxd noch zu wenig kenne um sinnvolle Aussagen machen zu können). Und ein bisschen PHP, RPM und debian bauen, und was man sonst so braucht.

/// Jürgen

[Sipple]

Hat geklappt. Danke!!!

[Smurf]

Händisch geht das mit --force-overwrite (dpkg).
Ist im aktuellen Master bereits repariert.