srcpd-devel — Developers only

Re: [Srcpd-devel] [PATCH] Erste Patches =?ISO-8859-1?Q?f=FCr?= den Server (unspezifisch zu meinem Modul)

[Manuel B. <web...@ma...>]

Hallo!

Habe gerade angepasste Patches nach Matthias Änderungen ins CVS
eingecheckt. Wem's nicht gefällt, kann die Änderungen ja "reverten" ;-))

Änderungen betreffen netserver.c und srcp-ga.c

Ciao,
Manuel

-- 
web...@ma...
http://www.matronix.de - http://www.e-online.de/public/borchers

  4:37pm  up  3:41,  5 users,  load average: 0.08, 0.19, 0.18

[Srcpd-devel] Beschreibung meiner Hardware und Status meines Moduls

[Manuel B. <web...@ma...>]

Hi!

In der Hoffnung, dass alle Entwickler hier mit lesen, wollte ich mal
kurz meine Hardware hier vorstellen, für die ich ja ein Modul schreibe.

Meine Hardware basiert auf dem I2C-Bus der Firma Philips und die
eigentliche Motivation die Digitalisierung meiner Modellbahn von Hand zu
machen, war größten Teils der Kostenfaktor damals und das
nicht-aufgeben-wollen der analogen Steuerung.

Wie dem auch sei, ich hab sowieso immer viel Spaß an Elektronik gehabt
und auch das war ein entscheidender Faktor und so war damals diese
Steuerung geboren.

Im Laufe der Zeit hab ich mich immer mehr für Netzwerke, TCP/IP, etc
interessiert und wollte auch schon ein Protokoll zur Steuerung selbst
entwerfen; glücklicherweise bin ich dann über SRCP gestolpert :)

Wer noch weitere Details zu meiner Steuerung wissen möchte, dem kann ich
meine Homepage ans Herz legen. Gerade eben bin ich mit dem Update der
Hardware-Seiten zu meiner neuen Version der Hardware fertig geworden.

http://www.matronix.de

Nun zum Status meines Moduls: Im Moment hab ich einen kleinen
Testaufbau, der nun auch mit der Modellbahn selber verbunden ist und ein
paar kleine Tests gemacht. Soweit scheint mein Modul recht sauber zu
laufen (nach Patch des Server-Codes, muss mal sehen in wie weit Matthias
meine Patches schon im CVS hat).

Bevor ich jetzt mein Modul ins CVS einchecke, ein paar Anmerkungen zu
meinem Modul.
Wie schon gesagt, verwende ich den I2C-Bus. Auf Grund des klasse
Kernel-supports von verschiedenen I2C-Adaptern, habe ich mich
entschieden den I2C-Bus nicht direkt zu steuern, sondern das
dev-Interface, das alle Kernel-Module unterstützt, zu verwenden.
Resultierend daraus, muss ich leider eine Kernel-Header-Datei
"includen":
#include <linux/i2c-dev.h>
ist der Übeltäter.

Das wiederum bedeutet, dass derjenige, der den srcpd selbst compilieren
möchte, auch den Kernel-Source-Code auf der Platte haben muss.

Ist das okay für euch oder sollte ich deshalb mein Modul lieber in einer
eigenen Branch weiter entwickeln?
Gerade in Anbetracht der Tatsache, dass mit mir ein neuer Entwickler für
einen FreeBSD-Port beigetreten ist, würde gerade das zu noch mehr
Problemen führen...

Soviel erst mal von meiner Seite!
Viele Grüße,
Manuel

-- 
web...@ma...
http://www.matronix.de - http://www.e-online.de/public/borchers

  3:45pm  up  2:50,  3 users,  load average: 0.19, 0.32, 0.28

[Srcpd-devel] [Fwd: Re: AW: srcpd Problem]

[Matthias T. <mt...@we...>]

-------- Original Message --------
Date: Sun, 05 Jan 2003 10:49:08 +0100
From: Matthias Trute <mt...@we...>
To: Michael A. Meiszl <Michael@Meiszl.De>
Subject: Re: AW: srcpd Problem

Michael A. Meiszl wrote:

>>Gut luck
>=20
> Du hast vergessen </sarkasmus on> :-)

wieso? Der Wunsch war ehrlich gemeint!

>=20
> Aaaalso....
> Ich hab mir erfolgreich (!) den Ast srcpd gesaugt und finde da auch vie=
le h=FCbsche Files, nur kein Makefile.in.

In der (neuesten) Doku steht drin, das man erst ein "make -f
Makefile.dist" machen mu=DF. Das erzeugt alles n=F6tige.

> Als n=E4chstes hat mich autoconfig ge=E4rgert, w=E4re zu alt f=FCr dies=
e supermoderne Zeuchs.

Tja. Zu unserer bisherigen Entwicklungsumgeung ist zu sagen, das ich auf
den SuSE-Varianten 7.3 und 8.1 herumgurke, Frank sich f=FCr gew=F6hnlich =
die
neuesten Versionen installiert (inkl. libc). Folgende Versionen habe ich
installiert (alles so ab SuSE8, die 7.3er Version habe ich nur um ein
aktualisiertes autoconf erweitert):

autoconf 2.52
automake 1.5
binutils 2.11.92
gcc: 2.95.3
glibc 2.2.5
libxml2 2.4.21
linux 2.4.18

Frank hat WIMRE neuere Versionen (gcc 3.2 usw). Bislang gab es nur
dahingehend Probleme, das meine Versionen zu alt waren, da ich aber
meine, das auch die Benutzer von Standardinstallationen den Code
=FCbersetzen k=F6nnen sollen, stand ich da bislang eher auf der Bremse.
Dies galt naturgem=E4=DF nur f=FCr Linux (resp darauf aufbauenden
Distributionen)

> </schweissabwisch off>

Zu fr=FCh ;=3D)

> Nur brachte mich das auch nicht so recht weiter, denn wo f=E4ngt man de=
nn nun an???

make -f Makefile.dist
configure
make

> (Bevor solche Ideen wie kde usw kommen, hier gibt's nur Hardcore Unix!)=


Naja, FreeBSD ist nix gegen AIX und Konsorten.

Der Einfachheit halber jetzt auch die Antwirten auf die anderen Mails:

Da ich keine Ahnung von cvsup habe, kann ich Dir nicht sagen, ob das a)
branchf=E4hig ist und b) wie man damit ins Repository hinschreibt.

F=FCr CVS selbst gibt es sehr sch=F6ne Oberfl=E4chen (www.wincvs.org oder=
 com
sowie www.cvshome.org haben praktische Programme und Links auf solche
(nicht nur f=FCr win, wie der Name vermuten lie=DFe). Auch gef=E4llt mir =
das
Buch von Karl Fogel sehr gut (cvs und OpenSource).

F=FCr das weitere Vorgehen warte ich ab, bis Du die stdincludes.h drin
hast, bis dahin habe ich vielleicht auch den INFO Modus etwas debuggt
und ich mache eine weitere Betafassung. Dann branchen wir auf dieser
Betafassung. Dieser Branch wird sich nur mit FreeBSD besch=E4ftigen, die
Linuxer werkeln weiter im Hauptzweig.

Damit kannst Du in aller Ruhe und ohne uns im HEAD zu "st=F6ren" basteln.=

Wenn Du soweit bist, mergen wir wieder und machen dann gemeinsam weiter.

Genau dies w=FCrde ich mit den von dir eingesandten tar-files machen, als=
o
ist es (f=FCr mich) einfacher, wenn du es selbst machst. Einverstanden?
Bei mir liegen die Patches ohnehin nur auf Halde, testen kann ich die eh
nicht (au=DFer, ob der Linuxport weiter funktioniert, aber da sind doch
sicher ein paar ifdef's drin, oder?).

Die pthread-Sache w=FCrde ich in die Rubrik "BSD Branch" werfen, zumindes=
t
solange es nicht via autoconf geregelt ist (oder vergleichbar einfach).

Den Branch werde ich dann voraussichtlich kommende Woche anlegen.

Was den sig11 angeht: Welcher Thread dumpt denn wo? Zumindest unter
Linux ist der gdb nicht threadf=E4hig, deswegen baue ich dann immer DBG
Aufrufe ein (ersatzweise syslog), um dem Ausstiegspunkt n=E4herzukommen.
M=FChselig, aber das ist das ganze Programmierergesch=E4ft ohnehin.

Matthias

PS: Follow-up gesetzt

Re: [Srcpd-devel] "schwaches" _GASTATE struct?

[Matthias T. <mt...@we...>]

Hi,

> Du meinst also, dass wir die Struktur dann nur noch intern im srcp-ga.c=

> zum Speichern des Status verwenden und die Module davon gar nichts mehr=

> wissen sollen, richtig?

Sollte man intensiv dr=FCber nachdenken.

> Dann hab ich am Wochenende ja nen bisschen was zu tun und werde da mal
> nen bissl tiefer in srcp-ga.c einsteigen ;)

Dann mach mal einen CVS Update. Ich habe grade ein bissel daran
herumgebastelt, um meine Clients weiterentwickeln zu k=F6nnen.
Ist nicht so ganz das geworden, was Dir so vorschwebt, aber
reicht f=FCr den Hausgebrauch.

Matthias

Re: [Srcpd-devel] "schwaches" _GASTATE struct?

[Manuel B. <web...@ma...>]

Hallo!

Am Fre, 2003-01-03 um 18.07 schrieb Matthias Trute:
> Eben deswegen würde ich die ganze Datenstruktur als static deklarieren
> und auch die Definition der Struktur aus dem .h ins .c transferieren.
> Dann haben wir da Ruhe.

Du meinst also, dass wir die Struktur dann nur noch intern im srcp-ga.c
zum Speichern des Status verwenden und die Module davon gar nichts mehr
wissen sollen, richtig?

Das wäre natürlich noch optimaler!

> Analog für die anderen Geräte (einiges sollte da schon solcherart
> gekapselt sein).

So weit hab ich mich noch nicht eingelesen, weil ich für meine Hardware
noch keine anderen "Devices" habe außer GA.
Dann hab ich am Wochenende ja nen bisschen was zu tun und werde da mal
nen bissl tiefer in srcp-ga.c einsteigen ;)

Viele Grüße,
Manuel

-- 
web...@ma...
http://www.matronix.de - http://www.e-online.de/public/borchers

  1:32pm  up 41 min,  3 users,  load average: 0.10, 0.26, 0.43

Re: [Srcpd-devel] DBG() Probleme

[Manuel B. <web...@ma...>]

Hallo!

Am Fre, 2003-01-03 um 18.10 schrieb Matthias Trute:
> Kann in der Tat schweißtreibend sein ;=)

Dat is wohl wahr ;) ich hab mir erst mal so geholfen, dass ich direkt
auf stdout meinen Debug-Kram ausgebe... das Optimum ist das allerdings
nicht ;)

> Das scheint dann aber eher ein Problem der Konfiguration zu sein
> denn des Codes. Bei mir produziert der m605x Code ggf. massenhaft
> syslog-Output.

Das hab ich mir auch schon gedacht, leider noch keine Lösung gefunden,
muss mal nachforschen, was RedHat da wohl in der syslog-Konfig
verbrochen hat...

> Welche srcpd.conf wird genommen und was steht da drin? Der Parser
> ist noch nicht sehr auskunftsfreudig bei Problemen... Setz mal den
> verbosity level des Servers (bus 0) auf 5. Dann kommen einige Angaben
> mehr. (zumindest bei mir).

Bei mir kommt so gut wie gar nix, nur dass zwei Threads gestartet werden
und gestartet wurden...
Anbei meine srcpd.conf

> Oder ist das Problem schon ein historisches?

Leider nicht...
Werde mich heute mal intensiv damit beschäftigen.

Ciao,
Manuel

-- 
web...@ma...
http://www.matronix.de - http://www.e-online.de/public/borchers

  1:26pm  up 35 min,  3 users,  load average: 0.18, 0.29, 0.48

Re: [Srcpd-devel] "schwaches" _GASTATE struct?

[Matthias T. <mt...@we...>]

Hallole,

Manuel Borchers wrote:

> Als ich aber so angefangen habe nachzuvollziehen, was wir da alles in
> die Antwort packen, ist mir aufgefallen, dass das _GASTATE struct
> eigentlich zu "schwach" ist.

Bleibt die Frage, ob wir die Schnittstelle "=F6ffentlich" lassen.=20
Eigentlich ist die struct zu kompliziert daf=FCr. Die unqueue-Befehle
lie=DFen sich sicher auch so umstricken, das sie keine _GA struct benutze=
n
m=FCssen (zu fett f=FCr diesen Zweck).

Intern ist Deine =C4nderung ohne Zweifel notwendig.

> Wie w=E4re es, wenn wir auf folgendes =E4ndern? (Bin leider noch nicht =
allzu
> fit mit structs und so, also korrigiert mich, wenn ich da v=F6lligen mu=
rks
> produziere):
=2E..
>=20
> Diese =C4nderung zieht nat=FCrlich =C4nderungen in allen Modulen nach s=
ich,

Eben deswegen w=FCrde ich die ganze Datenstruktur als static deklarieren
und auch die Definition der Struktur aus dem .h ins .c transferieren.
Dann haben wir da Ruhe.

Analog f=FCr die anderen Ger=E4te (einiges sollte da schon solcherart
gekapselt sein).

> Was meint ihr zu dem Vorschlag?

Neue Besen kehren gut ;=3D)

Gru=DF
Matthias

Re: [Srcpd-devel] DBG() Probleme

[Matthias T. <mt...@we...>]

Hallole,

> Allerdings habe ich ein kleines Problem: Ich bekomme keine
> Debug-Ausgaben! Ziemlich schwierig so irgendwas vern=FCnftig zu
> schreiben...

Kann in der Tat schwei=DFtreibend sein ;=3D)

>=20
> Meine eigenen Routinen geben nichts weiter aus, aber auch das
> loopback-Interaface und mit dem m605x ist es das selbe:

Das scheint dann aber eher ein Problem der Konfiguration zu sein
denn des Codes. Bei mir produziert der m605x Code ggf. massenhaft
syslog-Output.

Welche srcpd.conf wird genommen und was steht da drin? Der Parser
ist noch nicht sehr auskunftsfreudig bei Problemen... Setz mal den
verbosity level des Servers (bus 0) auf 5. Dann kommen einige Angaben
mehr. (zumindest bei mir).

Oder ist das Problem schon ein historisches?

Matthias

[Srcpd-devel] "schwaches" _GASTATE struct?

[Manuel B. <web...@ma...>]

Hallo, meiner welche schon wieder!

Ich bin gerade bisschen am Testen meines Moduls gewesen und hab Probleme
mit dem "GET <bus> GA" festgestellt.
Leider hängt sich der Server dabei immer weg, wenn er eine Antwort
generieren soll. Wieso hab ich noch nicht weiter raus, irgendwas stimmt
mit der Zeitangabe nicht.

Als ich aber so angefangen habe nachzuvollziehen, was wir da alles in
die Antwort packen, ist mir aufgefallen, dass das _GASTATE struct
eigentlich zu "schwach" ist.
Wir können zwar die Aktion des letzten Befehls auf einen Port
nachvollziehen, aber lt. SRCP-Spezifikation, sollten wir wenn wir auch
ein "GET 1 GA 1 1" verarbeiten können; also den Status eines bestimmten
Ports anzeigen können bzw. wenn wir ein "GET 1 GA 1" bekommen, den
Status beider Ports anzeigen...

Wie wäre es, wenn wir auf folgendes ändern? (Bin leider noch nicht allzu
fit mit structs und so, also korrigiert mich, wenn ich da völligen murks
produziere):

-- snip --
struct _GASTATE
{
  int action;
  long activetime;
  struct timeval tv;
  struct timeval t;
};

typedef struct _GA
{
  int numberOfGa;
  char *protocol;
  struct _GASTATE *gastate[MAXGAPORT];
  long int locked_by;
} GA;
-- /snip --

Diese Änderung zieht natürlich Änderungen in allen Modulen nach sich,
deshalb habe ich erst mal noch nichts weiter programmiert und werde in
meiner lokalen Kopie handleGET erst mal immer SRCP_NODATA zurück liefern
lassen...

Was meint ihr zu dem Vorschlag?

Gruß,
Manuel

-- 
web...@ma...
http://www.matronix.de - http://www.e-online.de/public/borchers

  3:02pm  up 1 day,  4:51,  6 users,  load average: 0.46, 0.46, 0.34

[Srcpd-devel] [PATCH] Erste Patches =?ISO-8859-1?Q?f=FCr?= den Server (unspezifisch zu meinem Modul)

[Manuel B. <web...@ma...>]

Hallöchen!

Nach einigen Tagen Einarbeitung, Rumprobieren und so weiter habe ich
auch schon die ersten Bugs im Server gefunden und bereinigt.

Hier die Auszüge aus den Datei-Köpfen:

== netserver.c ==

 * 2002-12-29 Manuel Borchers
 *            handleSET():
 *            - getlockGL changed to getlockGA in the GA-command-processing
 *            - if the device is locked, return code is now set to
 *              SRCP_DEVICELOCKED

== srcp-ga.c ==

 * 2002-12-29 Manuel Borchers
 *            - added ga[busnumber].gastate[addr].locked_by = 0 to the init-
 *              functions, because lockid = 0 should mean no lock; without
 *              this init it returned -1
 *


Ob letzteres bei allen gcc's nötig ist, weiß ich nicht. Uninitialisiert
ist locked_by mit gcc-3.2 bei mir jedenfalls immer -1 gewesen.
Besser zwei, drei Zeilen zur Initialisierung mehr, also sich auf den gcc
verlassen müssen :)

Anbei die diff's zu den CVS-Versionen.
Wäre schön, wenn das jemand (nach Prüfung) einchecken könnte.

Ich weiß nicht, wie intensiv ihr Gebrauch vom ChangeLog macht, deshalb
habe ich für die kleinen Änderungen keine Einträge geschrieben.

Wenn ich weiter mit meinem Modul fortgeschritten bin, würde ich sehr
gerne dem Entwicklerteam vom srcpd beitreten. CVS ist mir kein
Fremdwort, muss es recht oft wegen meiner Übersetzertätigkeit beim
GNOME-Desktop verwenden.

Also, viele Grüße und nen guten Rutsch!
Ciao,
Manuel

-- 
web...@ma...
http://www.matronix.de - http://www.e-online.de/public/borchers

  5:57pm  up 2 days, 22 min,  9 users,  load average: 0.12, 0.29, 0.35

[Srcpd-devel] DBG() Probleme

[Manuel B. <web...@ma...>]

Hallo, meiner welcher schon wieder ;)

Erst mal vielen Dank an Matthias für die schnelle Hilfe bzgl. des
compile-Problems. Lässt sich jetzt alles schön compilieren und ich habe
auch schon angefangen los zu programmieren.

Allerdings habe ich ein kleines Problem: Ich bekomme keine
Debug-Ausgaben! Ziemlich schwierig so irgendwas vernünftig zu
schreiben...

Meine eigenen Routinen geben nichts weiter aus, aber auch das
loopback-Interaface und mit dem m605x ist es das selbe:

-- snip --
Dec 27 18:26:35 newton srcpd: srcpd V2 BETA; SRCP 0.8
Dec 27 18:26:36 newton srcpd: Going to start 2 Interface Threads for the
busses
Dec 27 18:26:36 newton srcpd: going to start Interface Thread  1 type(8)
Dec 27 18:26:36 newton srcpd: Interface Thread 1 started successfully
type(8): pid 24580
Dec 27 18:26:36 newton srcpd: going to start Interface Thread  2 type(2)
Dec 27 18:26:36 newton srcpd: Interface Thread 2 started successfully
type(2): pid 32773
Dec 27 18:26:36 newton srcpd: All Threads started
-- /snip --

Das ist alles, was ich im syslog bekomme. verbosity steht in der Config
bei allen Interfaces auf 5...

Irgend eine Idee?

Grüße,
Manuel

-- 
web...@ma...
http://www.matronix.de - http://www.e-online.de/public/borchers

  6:24pm  up 49 min,  5 users,  load average: 0.95, 0.44, 0.25

[Fwd: Re: [Srcpd-devel] Problem mit CVS und Hallo erst mal]

[Matthias T. <mt...@we...>]

Wrong address...

-------- Original Message --------
Subject: Re: [Srcpd-devel] Problem mit CVS und Hallo erst mal
Date: Thu, 26 Dec 2002 17:38:09 +0100
From: Matthias Trute <mt...@we...>
To: Manuel Borchers <web...@ma...>
References: <104...@ne...z>

Hallo Manuel,

jetzt erst mal nur kurz, so zwischen zwei Terminen ;=3D)

> Und jetzt komm ich auch zu meinem eigentlichen Problem im Moment:
>=20
> [master@newton srcpd]$ ./configure --prefix=3D/opt/railroad
> checking for a BSD-compatible install... /usr/bin/install -c
> [...]
> configure: creating ./config.status
> config.status: creating Makefile
> config.status: error: cannot find input file: Makefile.in

zuerst ist ein "make -f Makefile.dist" angesagt. Das erzeugt
alle n=F6tigen Files. Danach wird dann der configure funktionieren.
L=FCcke in der Doku, sorry.

> Viele Gr=FC=DFe, frohe Rest-Weihnachten und einen guten Rutsch, w=FCnsc=
he ich
> allen!

Dito! und bis n=E4chstes Jahr!

Matthias

[Srcpd-devel] Problem mit CVS und Hallo erst mal

[Manuel B. <web...@ma...>]

Hallo alle zusammen!

Mein Name ist Manuel Borchers und ich bin neu auf dieser Liste und auch
neu beim scrpd.
Modellbahn ist schon lange mein Hobby und ich arbeite schon relativ
lange an einer eigenes entwickelten Digitalsteuerung meiner analogen
Märklin Anlage.

Mein Ziel dabei ist es nicht kompatibel zu MM oder ähnlichem zu sein,
deshalb basiert meine Steuerung auf dem I2C-Bus. Derzeit habe ich nur
eine Relaiskarte zur Steuerung von Magnetartikeln und Aktivierung von
Abstellgleisen.

Wie dem auch sei, bei meinen Recherchen bin ich auf das SRCP gestoßen
und dachte mir, dass ich mit meiner Software dazu kompatibel sein
möchte, um die schönen Clients nutzen zu können :)

Dabei bin ich auch auf den scrpd gestoßen, der in seiner 2.0er Beta ja
einen wirklich schönen modularen Aufbau hat. Ich hab mich jetzt zwei
Tage lang ein wenig in den Source-Code eingelesen und stehe kurz davor
loszulegen und ein Modul für mein I2C-Interface (oder jedes andere, dass
vom Linux-Kernel unterstützt wird) zu schreiben.
Dazu habe ich mir erst mal einen frischen CVS-CheckOut besorgt und
wollte den erst mal so wie er ist compilieren.

Und jetzt komm ich auch zu meinem eigentlichen Problem im Moment:

[master@newton srcpd]$ ./configure --prefix=/opt/railroad
checking for a BSD-compatible install... /usr/bin/install -c
[...]
configure: creating ./config.status
config.status: creating Makefile
config.status: error: cannot find input file: Makefile.in


In autoconf und automake bin ich leider nicht allzu fit und weiß mir an
dieser Stelle nicht weiter zu helfen.

Über jegliche Hilfe würde ich mich freuen!

Viele Grüße, frohe Rest-Weihnachten und einen guten Rutsch, wünsche ich
allen!

Ciao,
Manuel

-- 
web...@ma...
http://www.matronix.de - http://www.e-online.de/public/borchers

  4:04pm  up  2:44,  5 users,  load average: 0.48, 0.23, 0.25