patch

Eigene Aenderungen durch Patchen

Da einige HCAN Anwender Erweiterungen oder Aenderungen durchfuehren moechten, soll hier ein praktikabler Weg beschrieben werden.

ACHTUNG: Das sei gleich von Anfang an gesagt: Es werden nur ausgewaehlte Aenderungen uebernommen. Denn das bedeutet: Testen, Verstehen, Anpassungen, Debugging etc. Diesen Aufwand moechte keiner nutzlos haben. Jeder hier steckt schon genug Zeit in HCAN - eigene Wuensche zu realisieren macht Spass, Aenderungen fuer andere Leute ist eine Arbeit.

Eigene Aenderungen koennen in HCAN in Form von Patches vorgenommen werden. Dies ist in der Opensource Szene eine uebliche Vorgehensweise - man denke z.B. an diverse Kernel-Patches, die separat gepflegt werden. Sie enthalten die speziellen Aenderungen, die der Entwickler gerne im Kernel haette. Anwender oder der Entwickler selbst koennen dann den Patch gegen den Standard-Kernel einfahren, muessen es aber nicht. Die Kernel-Entwickler des Standard-Kernels haben damit keine Arbeit.

Ein Patch ist eine Datei, welche die Aenderungen gegenueber einer bestimmten Code-Basis beschreibt. Diese Datei erzeugt man mit dem Tool diff. Details finden sich in der Manpage von diff.

Hat man dann einen Patch vorliegen, kann man diesen mit dem Tool patch in eine Codebasis einfahren. Im Normalfall ist dies der gleicher Codebaum, gegenueber dem die Aenderungen mit diff extrahiert wurden. Man kann nun aber auch den Patch gehen eine neuere Version der urspruenglichen Code-Basis einfahren - solange die Aenderungen nicht mit anderen Aenderungen kollidieren, geht das in der Praxis recht reibungslos.

Ein Beispiel einer Aenderung

Entwickler Eddie will die Standard-Entprellzeit der Taster von 30ms auf 60ms aendern. Dazu ist folgendes noetig:

• der Codebaum von hcan muss vorliegen

• der Codebaum wird kopiert, so dass Aenderungen in dieser Kopie vorgenommen werden koennen

• die Aenderungen werden in der Kopie vorgenommen

• mit diff wird ein Patch erzeugt

• dieses kann nun gegen den Ursprungsbaum eingefahren werden, und damit sind alle Aenderungen vorgenommen

Das sieht im Detail so aus:

$ tar xvfz /pfad/zu/hcan-2.0.tar.gz
$ mv hcan hcan-2.0-orig
$ cp -r hcan-2.0-orig hcan-2.0-eddie-60ms

Die Datei hcan-2.0-eddie-60ms/firmwares/controllerboard-1612-v01/taster.c nun editieren; in der Zeile 62 den Wert von 3 auf 6 aendern, und etwas kommentieren.

Nun wird der Patch erzeugt:

$ diff -urN hcan-2.0-orig hcan-2.0-eddie-60ms > hcan-2.0-eddie-60ms.patch

Ist der Patch gross, kann er auch direkt gezipped werden:

$ diff -urN hcan-2.0-orig hcan-2.0-eddie-60ms | gzip -c > hcan-2.0-eddie-60ms.patch.gz

Der Patch sieht jetzt so aus:

diff -urN hcan-2.0-orig/firmwares/controllerboard-1612-v01/taster.c hcan-2.0-eddie-60ms/firmwares/controllerboard-1612-v01/taster.c
-- hcan-2.0-orig/firmwares/controllerboard-1612-v01/taster.c   2009-01-23 11:03:53.000000000 +0100
+++ hcan-2.0-eddie-60ms/firmwares/controllerboard-1612-v01/taster.c     2009-02-07 18:17:50.000000000 +0100
@@ -56,12 +56,15 @@
              p->pressed = 0;
      }

+       // eddie-60ms Patch:
+       //
+       // Die Standard-Entprellzeit auf 60ms aendern
      if (p->config.feature & 0x01)
              time = 100;
      else
-               time = 3;
+               time = 6; // Wert in 1/100s, somit 60ms

-       if (p->pressed == time) // mind. 30msec gedrueckt
+       if (p->pressed == time) // mind. 60msec gedrueckt
      {
              message.data[1] = HCAN_HES_TASTER_DOWN;
              canix_frame_send_with_prio(&message, HCAN_PRIO_HI);

Anwender Alfred will nun Eddie's Aenderungen haben; dazu nimmt er sich den hcan-2.0 Codebaum und spielt den Patch von Eddie ein:

$ tar xvfz /pfad/zu/hcan-2.0.tar.gz
$ cd hcan
$ zcat /pfad/zum/hcan-2.0-eddie-60ms.patch.gz | patch -p1
patching file firmwares/controllerboard-1612-v01/taster.c
$

Damit ist die Sache erledigt. Wenn Anwender Alfred nun ein Problem hat und den Patch als Ursache vermutet, kann er den Patch "rauspatchen":

$ cd hcan
$ zcat /pfad/zum/hcan-2.0-eddie-60ms.patch.gz | patch -p1 -R
patching file firmwares/controllerboard-1612-v01/taster.c
$

Jetzt sind die Aenderungen wieder rueckgaengig gemacht.

Solange nun in einer neueren Version von HCAN keine Aenderungen im Bereich der Zeile 60 in firmwares/controllerboard-1612-v01/taster.c passiert sind, laesst sich der Patch auch gegen diese neue Version einfahren.

Sollten Aenderungen stattgefunden haben, so meckert patch:

$ tar xvfz /pfad/zu/hcan-3.0.tar.gz
$ cd hcan
$ zcat /pfad/zum/hcan-2.0-eddie-60ms.patch.gz | patch -p1
patching file firmwares/controllerboard-1612-v01/taster.c
Hunk #1 FAILED at 56.
1 out of 1 hunk FAILED -- saving rejects to file firmwares/controllerboard-1612-v01/taster.c.rej

patch konnte den Patch nicht einspielen, weil die Aenderungen kollidieren; das File firmwares/controllerboard-1612-v01/taster.c.rej zeigt, wo das Problem liegt:

**************
** 56,67 ****
      p->pressed = 0;
  }

  if (p->config.feature & 0x01)
      time = 100;
  else
-     time = 3;

- if (p->pressed == time) // mind. 30msec gedrueckt
  {
      message.data[1] = HCAN_HES_TASTER_DOWN;
      canix_frame_send_with_prio(&message, HCAN_PRIO_HI);
-- 56,70 ----
      p->pressed = 0;
  }

+ // eddie-60ms Patch:
+ //
+ // Die Standard-Entprellzeit auf 60ms aendern
  if (p->config.feature & 0x01)
      time = 100;
  else
+       time = 6; // Wert in 1/100s, somit 60ms

+ if (p->pressed == time) // mind. 60msec gedrueckt
  {
      message.data[1] = HCAN_HES_TASTER_DOWN;
      canix_frame_send_with_prio(&message, HCAN_PRIO_HI);

Nun muss Eddie Hand anlegen und seine Aenderungen gegen die Version 3.0 durchfuehren.

patch ist aber (lt. Manpage) recht schlau und kann z.B. auch Patches einfahren, wenn sich die Zeilen sehr stark verschoben haben.