Code Restrukturierung - 2009: Unterschied zwischen den Versionen
(→Verzeichnisebenen) |
|||
| Zeile 1: | Zeile 1: | ||
== Verzeichnisebenen == | == Verzeichnisebenen == | ||
| − | + | Editieren erwünscht (mit Signatur wäre klasse) ;) | |
| − | Hab auch mal im Haupt Repository eine Branch mit Namen wip-refak erstellt und schon Änderungen | + | * Hab auch mal im Haupt Repository eine Branch mit Namen wip-refak erstellt und schon Änderungen eingecheckt. Da ich wegen fehlender Pin Einträge nicht alles kompilieren kann, ist auch nicht alles getestet. Alle Module prüfen kann man ja abschließend noch einmal tun. --13:17, 7. Apr. 2009 (UTC)~~ |
| − | eingecheckt. Da ich wegen fehlender Pin Einträge nicht alles kompilieren kann, ist auch nicht alles | ||
| − | getestet. Alle Module prüfen kann man ja abschließend noch einmal tun. | ||
| + | === Root === | ||
ethersex.c (Hauptschleife) | ethersex.c (Hauptschleife) | ||
| Zeile 13: | Zeile 12: | ||
crypto/... | crypto/... | ||
| + | * Der net Ordner wird aufgelöst. | ||
| + | * pt: Header Datei auflösen und in Core Dateien eingliedern | ||
| + | * mcuf: Aufsplitten in service/hardware/protocols Teile? | ||
| + | * pinning und scripts evtl in einen "build" Verzeichnis? | ||
| + | * Keine Ahnung wofür das hier da ist: ipchair | ||
| + | ** ipchair ist ein einfacher Paketfilter im Stile von iptables, deswegen auch der Name ;-) | ||
| + | ** gehört meines Erachtens dann unter core/ --[[Benutzer:Stesie|stesie]] 05:52, 7. Apr. 2009 (UTC) | ||
| + | *** ok --13:17, 7. Apr. 2009 (UTC)~~ | ||
| + | |||
| + | === Core === | ||
core/ | core/ | ||
eeprom.c | eeprom.c | ||
| Zeile 28: | Zeile 37: | ||
* watchcat/ könnten wir auch unter applications/services packen. Das guckt ja lediglich ob sich irgendwelche Pins ändern und sendet ggf. ECMDs. --[[Benutzer:Stesie|stesie]] 05:52, 7. Apr. 2009 (UTC) | * watchcat/ könnten wir auch unter applications/services packen. Das guckt ja lediglich ob sich irgendwelche Pins ändern und sendet ggf. ECMDs. --[[Benutzer:Stesie|stesie]] 05:52, 7. Apr. 2009 (UTC) | ||
| + | ** jep , sehe ich auch so. D.h. neue Position ist unter services --13:17, 7. Apr. 2009 (UTC)~~ | ||
* named_pin kann dann auch seinen festen Platz in portio/ finden, ohne Unterverzeichnis. --[[Benutzer:Stesie|stesie]] 05:52, 7. Apr. 2009 (UTC) | * named_pin kann dann auch seinen festen Platz in portio/ finden, ohne Unterverzeichnis. --[[Benutzer:Stesie|stesie]] 05:52, 7. Apr. 2009 (UTC) | ||
| + | ** hast recht --13:17, 7. Apr. 2009 (UTC)~~ | ||
| + | === External hardware === | ||
hardware/ | hardware/ | ||
infrared/ | infrared/ | ||
| Zeile 56: | Zeile 68: | ||
sd_reader/... | sd_reader/... | ||
| + | === Protocols === | ||
protocols/ | protocols/ | ||
uip/... | uip/... | ||
| Zeile 69: | Zeile 82: | ||
* uip/ und ipv6.c hätte ich jetzt noch nach core, sodass in protocols nur Anwendungsprotokolle sind. USB gehört da ebenfalls nur halb rein, weil das ja z.B. auch für ECMD bzw. eigene Entwicklungen genutzt werden kann. --[[Benutzer:Stesie|stesie]] 06:38, 7. Apr. 2009 (UTC) | * uip/ und ipv6.c hätte ich jetzt noch nach core, sodass in protocols nur Anwendungsprotokolle sind. USB gehört da ebenfalls nur halb rein, weil das ja z.B. auch für ECMD bzw. eigene Entwicklungen genutzt werden kann. --[[Benutzer:Stesie|stesie]] 06:38, 7. Apr. 2009 (UTC) | ||
| + | ** ist wirklich nicht leicht zu trennen, aber man muss sich überlegen, dass wir keine atmega hardware für das usb Protokoll und das ethernet Protokol haben, sondern diese Protokolle nur per software nachbauen, daher wäre ich eher tendenziel für "protocols" --13:17, 7. Apr. 2009 (UTC)~~ | ||
| + | === Services aka Applications === | ||
services/ | services/ | ||
clock/... | clock/... | ||
| Zeile 82: | Zeile 97: | ||
pwm/... | pwm/... | ||
tftp/... | tftp/... | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
== Modular == | == Modular == | ||
Imho sollte darauf hin gearbeitet werden, dass zumindest alle Dateien im Core keine Abhängigkeiten zu Modulen außerhalb haben, d.h. keine #ifdef MODUL_IRGENDWAS mehr. Ob sich das realisieren lässt ist noch die Frage. [[Benutzer:Rayofhope|Rayofhope]] | Imho sollte darauf hin gearbeitet werden, dass zumindest alle Dateien im Core keine Abhängigkeiten zu Modulen außerhalb haben, d.h. keine #ifdef MODUL_IRGENDWAS mehr. Ob sich das realisieren lässt ist noch die Frage. [[Benutzer:Rayofhope|Rayofhope]] | ||
* zugegeben, wir sollten gegen die vielen #ifdef vorgehen, aber alle wirst du nicht aus core/ rausbekommen | * zugegeben, wir sollten gegen die vielen #ifdef vorgehen, aber alle wirst du nicht aus core/ rausbekommen | ||
| + | ** Vielleicht mit Hilfe von m4, dass und eine c Datei generiert mit alle Modulen die z.B. Initialisiert werden wollen. Das werde ich auch erst prüfen, wenn die Verzeichnisse stehen. [[Benutzer:Rayofhope|Rayofhope]] | ||
* das neue Make-System ermöglicht uns auch leichter auf #ifdef zu verzichten, da man Blöcke, die von #ifdef umschlossen werden müssten in eigene Dateien speichern und die dann in Abhängigkeit von einem Symbol kompilieren kann --[[Benutzer:Stesie|stesie]] 05:56, 7. Apr. 2009 (UTC) | * das neue Make-System ermöglicht uns auch leichter auf #ifdef zu verzichten, da man Blöcke, die von #ifdef umschlossen werden müssten in eigene Dateien speichern und die dann in Abhängigkeit von einem Symbol kompilieren kann --[[Benutzer:Stesie|stesie]] 05:56, 7. Apr. 2009 (UTC) | ||
Version vom 7. April 2009, 14:17 Uhr
Inhaltsverzeichnis
Verzeichnisebenen
Editieren erwünscht (mit Signatur wäre klasse) ;)
- Hab auch mal im Haupt Repository eine Branch mit Namen wip-refak erstellt und schon Änderungen eingecheckt. Da ich wegen fehlender Pin Einträge nicht alles kompilieren kann, ist auch nicht alles getestet. Alle Module prüfen kann man ja abschließend noch einmal tun. --13:17, 7. Apr. 2009 (UTC)~~
Root
ethersex.c (Hauptschleife)
contrib/... control6/... doc/... vfs/... crypto/...
- Der net Ordner wird aufgelöst.
- pt: Header Datei auflösen und in Core Dateien eingliedern
- mcuf: Aufsplitten in service/hardware/protocols Teile?
- pinning und scripts evtl in einen "build" Verzeichnis?
- Keine Ahnung wofür das hier da ist: ipchair
- ipchair ist ein einfacher Paketfilter im Stile von iptables, deswegen auch der Name ;-)
- gehört meines Erachtens dann unter core/ --stesie 05:52, 7. Apr. 2009 (UTC)
- ok --13:17, 7. Apr. 2009 (UTC)~~
Core
core/ eeprom.c spi.c portio.c periodic.c (jetzt: timer.c) usart.c setbaud.h soft_uart.c timer.h (Timer Abstraktion: erstmal nur Präpro./Makros)pinning.cportio/watchcat/...named_pin/... (evtl umbennen in named_pins?)
- watchcat/ könnten wir auch unter applications/services packen. Das guckt ja lediglich ob sich irgendwelche Pins ändern und sendet ggf. ECMDs. --stesie 05:52, 7. Apr. 2009 (UTC)
- jep , sehe ich auch so. D.h. neue Position ist unter services --13:17, 7. Apr. 2009 (UTC)~~
- named_pin kann dann auch seinen festen Platz in portio/ finden, ohne Unterverzeichnis. --stesie 05:52, 7. Apr. 2009 (UTC)
- hast recht --13:17, 7. Apr. 2009 (UTC)~~
External hardware
hardware/ infrared/ rc5/... (hier senden und empfangen von rc5) adc/ kty/... i2c/ master/... (vorher: i2c_master) slave/... (vorher: i2c_slave) onewire/... input/ ps2 io_expander/ hc165 hc595 clock/ dcf77/... net/ enc28j60.c radio/ rfm12/... fs20/.. camera/... storage/ dataflash/... sd_reader/...
Protocols
protocols/ uip/... ipv6/ipv6.c usb/... zbus/... yport/... bootp/... mysql/... modbus/... msdns_sd/... ecmd/... (vorher: ecmd_parser+ecmd_serial; allerdings wirklich nur der parser mit seriell+net Anbindung. Modul spezisches sollte in den jeweiligen Modulordnern untergracht sein.)
- uip/ und ipv6.c hätte ich jetzt noch nach core, sodass in protocols nur Anwendungsprotokolle sind. USB gehört da ebenfalls nur halb rein, weil das ja z.B. auch für ECMD bzw. eigene Entwicklungen genutzt werden kann. --stesie 06:38, 7. Apr. 2009 (UTC)
- ist wirklich nicht leicht zu trennen, aber man muss sich überlegen, dass wir keine atmega hardware für das usb Protokoll und das ethernet Protokol haben, sondern diese Protokolle nur per software nachbauen, daher wäre ich eher tendenziel für "protocols" --13:17, 7. Apr. 2009 (UTC)~~
Services aka Applications
services/ clock/... cron/... dns/... dyndns/... httpd/... ntp/... jabber/... snmp/... stella/... pwm/... tftp/...
Modular
Imho sollte darauf hin gearbeitet werden, dass zumindest alle Dateien im Core keine Abhängigkeiten zu Modulen außerhalb haben, d.h. keine #ifdef MODUL_IRGENDWAS mehr. Ob sich das realisieren lässt ist noch die Frage. Rayofhope
- zugegeben, wir sollten gegen die vielen #ifdef vorgehen, aber alle wirst du nicht aus core/ rausbekommen
- Vielleicht mit Hilfe von m4, dass und eine c Datei generiert mit alle Modulen die z.B. Initialisiert werden wollen. Das werde ich auch erst prüfen, wenn die Verzeichnisse stehen. Rayofhope
- das neue Make-System ermöglicht uns auch leichter auf #ifdef zu verzichten, da man Blöcke, die von #ifdef umschlossen werden müssten in eigene Dateien speichern und die dann in Abhängigkeit von einem Symbol kompilieren kann --stesie 05:56, 7. Apr. 2009 (UTC)
