Ich bin ein bisschen enttäuscht. SuSE war immer "die" Distribution für ISDN. OpenSuSE 10.2 hat mit Version 2.6.18.2 endlich einen Kernel, in dem die ISDN-Treiber für die Siemens Gigaset SX255 und Verwandte integriert sind. Eine angeschlossene Gigaset-Basis oder ein M105 USB-Adapter werden korrekt aktiviert und dank udev auch mit der entsprechenden Gerätedatei /dev/ttyG[UB]0 verknüpft.
Aber unter "Netzwerkgeräte - ISDN" in YaST erscheinen sie nicht. Man kann sie nicht einmal über den Knopf "Hinzufügen" manuell eintragen, denn in den angebotenen Gerätelisten sind sie ebenfalls nicht aufgeführt - weder unter "Siemens" noch unter "Telekom".
Was kann ich als Mitentwickler dieser Treiber dazu beitragen, dass YaST sie in Zukunft korrekt erkennt und einbindet?
Außerdem gibt es auf http://sourceforge.net/projects/gigaset307x ein Software-Paket gigaset-frontend, das nützliche Dienstprogramme für die Benutzung dieser Geräte enthält. Gibt es eine Chance, dass dieses Paket in die OpenSuSE-Distribution aufgenommen wird, und was muss dafür geschehen?
Danke und fröhliche Weihnachten Tilman
Hi,
leider war ich längere Zeit krank, deshalb erst jetzt.
On Thu, Dec 21, 2006 at 04:28:26PM +0100, Tilman Schmidt wrote:
Ich bin ein bisschen enttäuscht. SuSE war immer "die" Distribution für ISDN. OpenSuSE 10.2 hat mit Version 2.6.18.2 endlich einen Kernel, in dem die ISDN-Treiber für die Siemens Gigaset SX255 und Verwandte integriert sind. Eine angeschlossene Gigaset-Basis oder ein M105 USB-Adapter werden korrekt aktiviert und dank udev auch mit der entsprechenden Gerätedatei /dev/ttyG[UB]0 verknüpft.
Aber unter "Netzwerkgeräte - ISDN" in YaST erscheinen sie nicht. Man kann sie nicht einmal über den Knopf "Hinzufügen" manuell eintragen, denn in den angebotenen Gerätelisten sind sie ebenfalls nicht aufgeführt - weder unter "Siemens" noch unter "Telekom".
Also um das erstmal zu testen reicht es entsprechende Einträge in /usr/share/hwinfo/ISDN.CDB.txt hinzuzufügen und anschliesend mk_isdnhwdb aufzurufen, das erzeugt die eigentliche Datenbank, danach sollte es mit YaST funktionieren.
Was kann ich als Mitentwickler dieser Treiber dazu beitragen, dass YaST sie in Zukunft korrekt erkennt und einbindet?
Mir dann ein diff der /usr/share/hwinfo/ISDN.CDB.txt schicken.
Außerdem gibt es auf http://sourceforge.net/projects/gigaset307x ein Software-Paket gigaset-frontend, das nützliche Dienstprogramme für die Benutzung dieser Geräte enthält. Gibt es eine Chance, dass dieses Paket in die OpenSuSE-Distribution aufgenommen wird, und was muss dafür geschehen?
Das wusste ich bei der Erstellung der 10.2 nicht.
Nicht viel, es muss eine saubere Lizenz geben und im Fall das da z.B. Firmware Files dabei sind, die Erlaubnis des Copyright Holders diese frei zu verteilen.
Ich denke ein Einzelpaket macht hier am meisten Sinn im Gegensatzt zur Integration in i4l-base.
Hallo,
Am 17.01.2007 01:17 schrieb Karsten Keil:
On Thu, Dec 21, 2006 at 04:28:26PM +0100, Tilman Schmidt wrote:
[...] OpenSuSE 10.2 hat mit Version 2.6.18.2 endlich einen Kernel, in dem die ISDN-Treiber für die Siemens Gigaset SX255 und Verwandte integriert sind. [...] Aber unter "Netzwerkgeräte - ISDN" in YaST erscheinen sie nicht. Man kann sie nicht einmal über den Knopf "Hinzufügen" manuell eintragen, denn in den angebotenen Gerätelisten sind sie ebenfalls nicht aufgeführt - weder unter "Siemens" noch unter "Telekom".
Also um das erstmal zu testen reicht es entsprechende Einträge in /usr/share/hwinfo/ISDN.CDB.txt hinzuzufügen und anschliesend mk_isdnhwdb aufzurufen, das erzeugt die eigentliche Datenbank, danach sollte es mit YaST funktionieren.
Ok, das ist schon mal ein guter Hinweis. Gibt es irgendwo noch nähere Informationen über das Format dieser Datei, Bedeutung und Wirkung der verschiedenen Einträge? - "vendor", "device" und "bus_type" sind ja recht klar - für "device_class" gibt es ein paar repräsentative Beispiele, von denen "ISDN Single Basic Rate" gut genug zu passen scheint - "line_cnt" und "line_protocol" sind auch durch Beispiele gut belegt - "alternative_name" scheint auch klar - aber darf ich das in einem Eintrag mehrfach verwenden? und ist das nur für wirklich baugleiche Geräte gedacht oder für generell schnittstellenkompatible? - "vendor_id" und "device_id" sind bei USB wohl die Werte aus dem USB Device Descriptor, bei RS232 entfallen sie ersatzlos? - "subvendor_id" und "subdevice_id" scheint es nur bei PCI zu geben? - "module", "need_packages" und "SMP" erscheinen auch recht eingängig - "firmware", "IO", "IRQ" und "MEMBASE" betreffen mich nicht - aber was ist "drv_id", "drv_typ", "drv_subtyp"? - was kann/muss ich bei "feature" angeben? wann ist z.B. die explizite Angabe "feature=Basic Rate" nötig und wann nicht? - wie verhalten sich "interface" und "vario" zueinander? - welche Funktionen haben "revision", "supported", "special"?
Was kann ich als Mitentwickler dieser Treiber dazu beitragen, dass YaST sie in Zukunft korrekt erkennt und einbindet?
Mir dann ein diff der /usr/share/hwinfo/ISDN.CDB.txt schicken.
Gerne, sobald ich etwas brauchbares habe.
Außerdem gibt es auf http://sourceforge.net/projects/gigaset307x ein Software-Paket gigaset-frontend, das nützliche Dienstprogramme für die Benutzung dieser Geräte enthält. Gibt es eine Chance, dass dieses Paket in die OpenSuSE-Distribution aufgenommen wird, und was muss dafür geschehen?
Nicht viel, es muss eine saubere Lizenz geben und im Fall das da z.B. Firmware Files dabei sind, die Erlaubnis des Copyright Holders diese frei zu verteilen.
Reine GPL, keine Firmware - denke, da wird es kein Problem geben.
Ich denke ein Einzelpaket macht hier am meisten Sinn im Gegensatzt zur Integration in i4l-base.
Auf jeden Fall. Die Tools werden auch nicht für die i4l-Funktion gebraucht, sondern stellen davon unabhängige Funktionen wie SMS oder Zugriff auf das Anlagen-Log zur Verfügung.
Danke Tilman
On Thu, Jan 18, 2007 at 01:45:19AM +0100, Tilman Schmidt wrote:
Hallo,
Am 17.01.2007 01:17 schrieb Karsten Keil:
On Thu, Dec 21, 2006 at 04:28:26PM +0100, Tilman Schmidt wrote:
[...] OpenSuSE 10.2 hat mit Version 2.6.18.2 endlich einen Kernel, in dem die ISDN-Treiber für die Siemens Gigaset SX255 und Verwandte integriert sind. [...] Aber unter "Netzwerkgeräte - ISDN" in YaST erscheinen sie nicht. Man kann sie nicht einmal über den Knopf "Hinzufügen" manuell eintragen, denn in den angebotenen Gerätelisten sind sie ebenfalls nicht aufgeführt - weder unter "Siemens" noch unter "Telekom".
Also um das erstmal zu testen reicht es entsprechende Einträge in /usr/share/hwinfo/ISDN.CDB.txt hinzuzufügen und anschliesend mk_isdnhwdb aufzurufen, das erzeugt die eigentliche Datenbank, danach sollte es mit YaST funktionieren.
Ok, das ist schon mal ein guter Hinweis. Gibt es irgendwo noch nähere Informationen über das Format dieser Datei, Bedeutung und Wirkung der verschiedenen Einträge?
- "vendor", "device" und "bus_type" sind ja recht klar
- für "device_class" gibt es ein paar repräsentative Beispiele, von denen "ISDN Single Basic Rate" gut genug zu passen scheint
Ja.
- "line_cnt" und "line_protocol" sind auch durch Beispiele gut belegt
- "alternative_name" scheint auch klar - aber darf ich das in einem Eintrag mehrfach verwenden? und ist das nur für wirklich baugleiche Geräte gedacht oder für generell schnittstellenkompatible?
Ist dafür gedacht wenn das Gerät mit identischen IDs auch als OEM auftaucht. Ob es mehrmals geht weiss ich im Moment auch nicht mehr, das Ganze habe ich vor ein paar Jahren in die hwlib gehackt, die Roh Daten stammen aus der SuSE HArdwaredatenbank für ISDN, die Sourcen die diese Daten auswerten finden sich im hwinfo Paket.
- "vendor_id" und "device_id" sind bei USB wohl die Werte aus dem USB Device Descriptor, bei RS232 entfallen sie ersatzlos?
Richtig.
- "subvendor_id" und "subdevice_id" scheint es nur bei PCI zu geben?
Ja.
- "module", "need_packages" und "SMP" erscheinen auch recht eingängig
- "firmware", "IO", "IRQ" und "MEMBASE" betreffen mich nicht
- aber was ist "drv_id", "drv_typ", "drv_subtyp"?
- was kann/muss ich bei "feature" angeben? wann ist z.B. die explizite Angabe "feature=Basic Rate" nötig und wann nicht?
drv_id ist eine eindeutige ID des Eintrags, sie darf nur einmal auftauchen. drv_id= drv_subtyp << 16 | drv_typ drv_typ=8100 (8101 usw. für jedes weitere HW modul am besten eine neue, verschieden Geraete die mit einem Modul gehandelt werden unterscheinen sich im drv_subtyp)
- wie verhalten sich "interface" und "vario" zueinander?
vario ist ein Treiber, da kann es mehrere alternative geben (z.B. bei der Fritz!PCI). Bitte verwende vario=I4L driver
interface kannst Du in jedem Fall I4L setzen und noch neue definieren für Deine Sonderfunktionen. Wird bisher nirgens ausgewertet.
- welche Funktionen haben "revision", "supported", "special"?
Revision ist nur wichtig wenn verschiedene Revisions (z.B. Revision Feld in der USB oder PCI Dev Table) unterschiedlich gehandelt werden müssen (z.B: verschiedene Firmware) aber die anderen IDs gleich sind. supported=full Treiber ist in der SuSEversion verfügbar und deckt die wichtigen Funktionen ab.
special ist nur für die AVM T1 da, da braucht man ein zusätzliches Auswahlkästchen im Konfigdialog.
Was kann ich als Mitentwickler dieser Treiber dazu beitragen, dass YaST sie in Zukunft korrekt erkennt und einbindet?
Mir dann ein diff der /usr/share/hwinfo/ISDN.CDB.txt schicken.
Gerne, sobald ich etwas brauchbares habe.
Außerdem gibt es auf http://sourceforge.net/projects/gigaset307x ein Software-Paket gigaset-frontend, das nützliche Dienstprogramme für die Benutzung dieser Geräte enthält. Gibt es eine Chance, dass dieses Paket in die OpenSuSE-Distribution aufgenommen wird, und was muss dafür geschehen?
Nicht viel, es muss eine saubere Lizenz geben und im Fall das da z.B. Firmware Files dabei sind, die Erlaubnis des Copyright Holders diese frei zu verteilen.
Reine GPL, keine Firmware - denke, da wird es kein Problem geben.
Ich denke ein Einzelpaket macht hier am meisten Sinn im Gegensatzt zur Integration in i4l-base.
Auf jeden Fall. Die Tools werden auch nicht für die i4l-Funktion gebraucht, sondern stellen davon unabhängige Funktionen wie SMS oder Zugriff auf das Anlagen-Log zur Verfügung.
Danke Tilman
-- Tilman Schmidt E-Mail: tilman@imap.cc Bonn, Germany Diese Nachricht besteht zu 100% aus wiederverwerteten Bits. Ungeöffnet mindestens haltbar bis: (siehe Rückseite)
Hallo Karsten,
Danke für die Tipps. Anhängend mein erster Entwurf für einen Patch. Er funktioniert soweit, jedenfalls bietet er angeschlossene USB-Geräte der Gigaset-Familie zur Konfiguration an und erzeugt Dateien in /etc/sysconfig/isdn, die weitgehend denen entsprechen, die unser eigenes Konfigurationsskript produziert. Ich teste aber noch ein bisschen weiter.
Offene Punkte bzw. Fragen bisher:
- Kann ich irgendwie erreichen, dass die "alternative_name" Einträge mit angezeigt werden? Von den Gigaset-Geräten gibt es ziemlich viele Varianten, die dieselbe USB-ID haben und auch identisch anzusteuern sind, aber ganz verschieden heißen und sogar unterschiedliche Gehäuse haben. Ein Benutzer, der eine "T-Com Sinus 45 AB isdn" hat, weiß nicht unbedingt, dass der Treiber "Siemens Gigaset SX255" für ihn der richtige ist ...
- Kann ich zusätzliche gerätespezifische Parameter abfragen und in Modulparameter übertragen lassen? Die Gigaset-Treiber haben einige Einstellungen, die über Modulparameter gesteuert werden. Unser bisheriges Setup-Skript fragt die ab und legt dafür eine Datei /etc/modules.conf.gigaset bzw. /etc/modprobe.d/gigaset an, die dann in /etc/modprobe.conf{,.local} included wird. Wäre nicht schlecht, wenn sich das in YaST nachbilden ließe.
- Kann ich einen Daemon-Prozess installieren und mit einem in YaST abzufragenden Parameter (Schnittstellendatei) starten lassen? Der Treiber für den RS232-Adapter Gigaset M101 data (noch nicht im Kernel) ist als serial line discipline realisiert und benötigt daher einen Userspace-Daemon, der ihn per TIOCSETD an die Schnittstelle bindet, an der das Gerät hängt.
- Kann ich aus der YaST-Konfiguration heraus einen Symlink anlegen? Unser bisheriges Setup-Skript legt einen generischen Symlink /dev/ttyG an, der auf die gerätespezifische Gerätedatei (z.B. /dev/ttyGB0 oder /dev/ttyGU0) verweist, damit die Nutzer der Frontend-Tools nicht jedesmal wissen und explizit angeben müssen, auf welchem Weg sie mit ihrer Gigaset-Basis kommunizieren; das hat sich für die Anwender als recht angenehm erwiesen.
- Muss/sollte ich irgendwelche Skripte in /etc/sysconfig/isdn/scripts für unsere Geräte anlegen? Andere ISDN-Geräte sind da ja reichhaltig vertreten, aber der Gigaset-Treiber funktioniert bisher auch so. Was entgeht uns da?
Danke Tilman
On Sat, Jan 20, 2007 at 03:10:39AM +0100, Tilman Schmidt wrote:
Hallo Karsten,
Danke für die Tipps. Anhängend mein erster Entwurf für einen Patch. Er funktioniert soweit, jedenfalls bietet er angeschlossene USB-Geräte der Gigaset-Familie zur Konfiguration an und erzeugt Dateien in /etc/sysconfig/isdn, die weitgehend denen entsprechen, die unser eigenes Konfigurationsskript produziert. Ich teste aber noch ein bisschen weiter.
Offene Punkte bzw. Fragen bisher:
- Kann ich irgendwie erreichen, dass die "alternative_name" Einträge mit angezeigt werden?
Muss ich mir mal anschauen, eigentlich war das so gedacht, kann aber sein das es nicht (mehr) so funktioniert.
Von den Gigaset-Geräten gibt es ziemlich viele Varianten, die dieselbe USB-ID haben und auch identisch anzusteuern sind, aber ganz verschieden heißen und sogar unterschiedliche Gehäuse haben. Ein Benutzer, der eine "T-Com Sinus 45 AB isdn" hat, weiß nicht unbedingt, dass der Treiber "Siemens Gigaset SX255" für ihn der richtige ist ...
Das war genau der Grund weshalb ich alternative_name eingführt habe, die FritzX gab es such mit verschiedenen Namen.
- Kann ich zusätzliche gerätespezifische Parameter abfragen und in Modulparameter übertragen lassen?
Jain. Im Moment gibt es da nur das special für die T1, das könnte man aber eventuell ausbauen.
Wieviele sind das, was gibt es für Werte ?
Die Gigaset-Treiber haben einige Einstellungen, die über Modulparameter gesteuert werden. Unser bisheriges Setup-Skript fragt die ab und legt dafür eine Datei /etc/modules.conf.gigaset bzw. /etc/modprobe.d/gigaset an, die dann in /etc/modprobe.conf{,.local} included wird. Wäre nicht schlecht, wenn sich das in YaST nachbilden ließe.
- Kann ich einen Daemon-Prozess installieren und mit einem in YaST abzufragenden Parameter (Schnittstellendatei) starten lassen?
Der Treiber für den RS232-Adapter Gigaset M101 data (noch nicht im Kernel) ist als serial line discipline realisiert und benötigt daher einen Userspace-Daemon, der ihn per TIOCSETD an die Schnittstelle bindet, an der das Gerät hängt.
Das sollte über /etc/init.d/gigaset gehen; gigaset Namen am Besten für den LSB conformen Service bei lanana reservieren, dann ist das bei allen Distris gleich, sonst muss er für uns suse-gigaset heissen. Auzug aus der LSB 3.1 http://refspecs.freestandards.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-generi...
16.2.1. File Naming Conventions Conforming implemetnations and applications installing files into any of the above locations under /etc may only use filenames from the following managed namespaces: Assigned names. Such names must be chosen from the character set [a-z0-9]. In order to avoid conflicts these names shall be reserved through the Linux Assigned Names and Numbers Authority (LANANA). Information about the LANANA may be found at www.lanana.org. Note: Commonly used names should be reserved in advance; developers for projects are encouraged to reserve names from LANANA, so that each distribution can use the same name, and to avoid conflicts with other projects.
Dieses script dann über Yast gegenfalls aufzurufen aufzurufen sollte kein großes Problem sein.
- Kann ich aus der YaST-Konfiguration heraus einen Symlink anlegen?
Unser bisheriges Setup-Skript legt einen generischen Symlink /dev/ttyG an, der auf die gerätespezifische Gerätedatei (z.B. /dev/ttyGB0 oder /dev/ttyGU0) verweist, damit die Nutzer der Frontend-Tools nicht jedesmal wissen und explizit angeben müssen, auf welchem Weg sie mit ihrer Gigaset-Basis kommunizieren; das hat sich für die Anwender als recht angenehm erwiesen.
Das könnte gegebenfalls im SuSEconfig.isdn script gemacht werden, das wird nach jeder Änderung im YaST ISDN Bereich einmal gestartet.
- Muss/sollte ich irgendwelche Skripte in /etc/sysconfig/isdn/scripts für unsere Geräte anlegen?
Andere ISDN-Geräte sind da ja reichhaltig vertreten, aber der Gigaset-Treiber funktioniert bisher auch so. Was entgeht uns da?
Dann ist da nichts notwendig, das Ganze ist eher historisch und hängt damit zusammen das z.B: HiSax auch einige Parameter braucht und ich die Möglichkeit haben wollte auch mehrere HiSax Karten flexibel zu handhaben.
Danke Tilman
-- Tilman Schmidt E-Mail: tilman@imap.cc Bonn, Germany Diese Nachricht besteht zu 100% aus wiederverwerteten Bits. Ungeöffnet mindestens haltbar bis: (siehe Rückseite)
--- /usr/share/hwinfo/ISDN.CDB.txt.orig 2007-01-20 00:53:50.000000000 +0100 +++ /usr/share/hwinfo/ISDN.CDB.txt 2007-01-20 01:50:34.000000000 +0100 @@ -179,3 +179,9 @@ |vendor=Sitecom|device=DC-104 USB ISDN Modem Rev 1|device_class=ISDN Single Basic Rate|bus_type=USB|vendor_id=0x0483|device_id=0x4810|subvendor_id=|subdevice_id=|vario=HiSax driver|SMP=Yes|drv_id=0x03e9|drv_subtyp=0|drv_typ=1001|interface=I4L|line_cnt=1|line_protocol=1TR6|line_protocol=DSS1|line_protocol=LEASED|line_protocol=NI1|module=hisax_st5481|need_packages=i4l-base|need_packages=i4l-isdnlog|supported=full| |vendor=Sitecom|device=DC 104 USB ISDN Modem Rev 2|device_class=ISDN Single Basic Rate|bus_type=USB|vendor_id=0x0959|device_id=0x2bd0|subvendor_id=|subdevice_id=|vario=HiSax driver|SMP=Yes|drv_id=0x103ea|drv_subtyp=1|drv_typ=1002|interface=I4L|line_cnt=1|line_protocol=1TR6|line_protocol=DSS1|line_protocol=LEASED|line_protocol=NI1|module=hfc_usb|supported=full| |vendor=Sitecom|device=DC 105 ISDN TA|device_class=ISDN Single Basic Rate|bus_type=PCI|vendor_id=0x182d|device_id=0x3069|subvendor_id=0x182d|subdevice_id=0x3069|vario=HiSax driver|SMP=Yes|drv_id=0x170023|drv_subtyp=23|drv_typ=35|interface=I4L|line_cnt=1|line_protocol=1TR6|line_protocol=DSS1|line_protocol=LEASED|line_protocol=NI1|module=hisax|supported=full| +|vendor=Siemens|device=Gigaset SX205|device_class=ISDN Single Basic Rate|bus_type=USB|vendor_id=0x0681|device_id=0x0001|vario=I4L driver|SMP=Yes|alternative_name=Gigaset 4170|alternative_name=Gigaset 3070|alternative_name=Telekom AG,Sinus 721 X|alternative_name=Telekom AG,Sinus 45 isdn|drv_id=0x11fa4|drv_subtyp=1|drv_typ=8100|interface=I4L|line_cnt=1|line_protocol=DSS1|module=bas_gigaset|need_packages=i4l-base|supported=full| +|vendor=Siemens|device=Gigaset SX255|device_class=ISDN Single Basic Rate|bus_type=USB|vendor_id=0x0681|device_id=0x0002|vario=I4L driver|SMP=Yes|alternative_name=Gigaset 4175|alternative_name=Gigaset 3075|alternative_name=Telekom AG,Sinus 721 XA|alternative_name=Telekom AG,Sinus 45 AB isdn|drv_id=0x21fa4|drv_subtyp=2|drv_typ=8100|interface=I4L|line_cnt=1|line_protocol=DSS1|module=bas_gigaset|need_packages=i4l-base|supported=full| +|vendor=Siemens|device=Gigaset SX303 isdn|device_class=ISDN Single Basic Rate|bus_type=USB|vendor_id=0x0681|device_id=0x0021|vario=I4L driver|SMP=Yes|drv_id=0x31fa4|drv_subtyp=3|drv_typ=8100|interface=I4L|line_cnt=1|line_protocol=DSS1|module=bas_gigaset|need_packages=i4l-base|supported=full| +|vendor=Siemens|device=Gigaset SX353 isdn|device_class=ISDN Single Basic Rate|bus_type=USB|vendor_id=0x0681|device_id=0x0022|vario=I4L driver|SMP=Yes|drv_id=0x41fa4|drv_subtyp=4|drv_typ=8100|interface=I4L|line_cnt=1|line_protocol=DSS1|module=bas_gigaset|need_packages=i4l-base|supported=full| +|vendor=Siemens|device=Gigaset M105 Data|device_class=ISDN Single Basic Rate|bus_type=USB|vendor_id=0x0681|device_id=0x0009|vario=I4L driver|SMP=Yes|alternative_name=Gigaset USB Adapter DECT|alternative_name=Telekom AG,Sinus 721 data|alternative_name=Telekom AG,Sinus 45 data 2|drv_id=0x1fa5|drv_subtyp=0|drv_typ=8101|interface=I4L|line_cnt=1|line_protocol=DSS1|module=usb_gigaset|need_packages=i4l-base|supported=full| +|vendor=Siemens|device=Gigaset M101 Data|device_class=ISDN Single Basic Rate|bus_type=Serial|vario=I4L driver|SMP=Yes|alternative_name=Telekom AG,Sinus 45 data 1|drv_id=0x1fa6|drv_subtyp=0|drv_typ=8102|interface=I4L|line_cnt=1|line_protocol=DSS1|module=ser_gigaset|need_packages=i4l-base|supported=full|
Am 20.01.2007 21:14 schrieb Karsten Keil:
On Sat, Jan 20, 2007 at 03:10:39AM +0100, Tilman Schmidt wrote:
- Kann ich zusätzliche gerätespezifische Parameter abfragen und in Modulparameter übertragen lassen?
Jain. Im Moment gibt es da nur das special für die T1, das könnte man aber eventuell ausbauen.
Wieviele sind das, was gibt es für Werte ?
Derzeit benutzen wir vier Modulparameter:
- für die Hardware-Module (bas_gigaset.ko, ser_gigaset-ko, usb_gigaset.ko): - cidmode=(0|1) steuert die Default-Betriebsart der AT-Schnittstelle (mit oder ohne Call-ID) - startmode=(0|1) legt fest, welche der beiden Software-Schnittstellen (I2L oder /dev/ttyG*) nach dem Treiberstart aktiv ist - für das hardwareunabhängige Modul (gigaset.ko): - debug=<bitmask> steuert den Umfang der Debug-Ausgabe, wenn der Treiber mit der Kconfig-Option GIGASET_DEBUG generiert wurde - für das Modul ppp_async müssen wir die Option flag_time=0 setzen, sonst funktioniert PPP über /dev/ttyG* nicht
Im Prinzip alles "nice to have", da (zumindest bei den Gigaset-Modulen) auch noch zur Laufzeit per sysfs bzw. Frontend-Tools steuerbar.
- Kann ich einen Daemon-Prozess installieren und mit einem in YaST abzufragenden Parameter (Schnittstellendatei) starten lassen?
Das sollte über /etc/init.d/gigaset gehen; gigaset Namen am Besten für den LSB conformen Service bei lanana reservieren, dann ist das bei allen Distris gleich, sonst muss er für uns suse-gigaset heissen.
Ok, werde ich mich drum kümmern.
Dieses script dann über Yast gegenfalls aufzurufen aufzurufen sollte kein großes Problem sein.
Das heißt also: 1. Ich baue ein Userspace-Paket mit dem Daemon und dem Init-Skript. 2. Das Init-Skript liest die Angabe der anzusprechenden Schnittstelle (z.B. /dev/ttyS1) aus einer geeigneten Datei unter /etc/sysconfig. (/etc/sysconfig/gigaset? Oder lieber eine der schon vorhandenen?) 3. YaST muss dann, wenn man ein ISDN-Gerät des Typs "Siemens Gigaset M101" installiert, abfragen, wo das Gerät angeschlossen ist, die entsprechende Gerätedatei als Parameter in die Sysconfig-Datei eintragen und den Systemdienst "gigaset" aktivieren. Wie erreiche ich 3.?
Unser bisheriges Setup-Skript legt einen generischen Symlink /dev/ttyG an, der auf die gerätespezifische Gerätedatei (z.B. /dev/ttyGB0 oder /dev/ttyGU0) verweist [...].
Das könnte gegebenfalls im SuSEconfig.isdn script gemacht werden, das wird nach jeder Änderung im YaST ISDN Bereich einmal gestartet.
Da ist dann halt die Frage, woher SuSEconfig.isdn weiß, welchen Symlink es setzen soll. Es können ja auch mehrere Gigaset-Geräte installiert sein, zum Beispiel eine Direktverbindung /dev/ttyGB0 und eine DECT- Verbindung /dev/ttyGU0. Bisher fragen wir den Benutzer einfach bei der Einrichtung jedes Geräts, ob es sein Standard-Gigaset-Zugang werden soll.
Danke Tilman
PS: Ich hatte in der Zwischenzeit https://bugzilla.novell.com/show_bug.cgi?id=234529 aufgemacht. Soll ich da irgendwie vermerken, dass wir das jetzt zusammen verhackstücken?
Hallo Karsten,
ich würde gerne den Faden "Integration Gigaset-Treiber in openSUSE 10.3" wieder aufnehmen.
Am 22.01.2007 18:36 schrieb ich:
Am 20.01.2007 21:14 schrieb Karsten Keil:
On Sat, Jan 20, 2007 at 03:10:39AM +0100, Tilman Schmidt wrote:
- Kann ich zusätzliche gerätespezifische Parameter abfragen und in Modulparameter übertragen lassen?
Jain. Im Moment gibt es da nur das special für die T1, das könnte man aber eventuell ausbauen.
Das, schlage vor, lassen wir erstmal ganz weg. Die Treiber funktionieren ja auch ohne das.
- Kann ich einen Daemon-Prozess installieren und mit einem in YaST abzufragenden Parameter (Schnittstellendatei) starten lassen?
Das sollte über /etc/init.d/gigaset gehen; gigaset Namen am Besten für den LSB conformen Service bei lanana reservieren, dann ist das bei allen Distris gleich, sonst muss er für uns suse-gigaset heissen.
Der Servicename "gigaset" ist mittlerweile für unser Projekt registriert. Offen ist damit aus meiner Sicht noch der Komplex:
- Ich baue ein Userspace-Paket mit dem Daemon und dem Init-Skript.
- Das Init-Skript liest die Angabe der anzusprechenden Schnittstelle (z.B. /dev/ttyS1) aus einer geeigneten Datei unter /etc/sysconfig. (/etc/sysconfig/gigaset? Oder lieber eine der schon vorhandenen?)
- YaST muss dann, wenn man ein ISDN-Gerät des Typs "Siemens Gigaset M101" installiert, abfragen, wo das Gerät angeschlossen ist, die entsprechende Gerätedatei als Parameter in die Sysconfig-Datei eintragen und den Systemdienst "gigaset" aktivieren.
Wie erreiche ich 3.?
Natürlich in umgekehrter Reihenfolge, d.h. für 1. brauche ich die Antworten auf 2. und 3.
Und als "nice to have":
Unser bisheriges Setup-Skript legt einen generischen Symlink /dev/ttyG an, der auf die gerätespezifische Gerätedatei (z.B. /dev/ttyGB0 oder /dev/ttyGU0) verweist [...].
Das könnte gegebenfalls im SuSEconfig.isdn script gemacht werden, das wird nach jeder Änderung im YaST ISDN Bereich einmal gestartet.
Da ist dann halt die Frage, woher SuSEconfig.isdn weiß, welchen Symlink es setzen soll. Es können ja auch mehrere Gigaset-Geräte installiert sein, [...]
Kann man, denke ich, auch erstmal vernachlässigen und bei mehreren Geräten willkürlich eins aussuchen.
Wie soll ich das einbauen? Einfach ans Ende anhängen, oder gibt es da einen geeigneteren Platz?
Danke, Tilman
-
Karsten Keil -
Tilman Schmidt