Code Restrukturierung - 2009
Version vom 7. April 2009, 06:56 Uhr von Stesie (Diskussion | Beiträge)
Verzeichnisebenen
Vorschlag von Rayofhope. Editieren erwünscht (mit Signatur wäre klasse) ;)
ethersex.c (Hauptschleife)
contrib/... control6/... doc/... vfs/... crypto/...
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)
- named_pin kann dann auch seinen festen Platz in portio/ finden, ohne Unterverzeichnis. --stesie 05:52, 7. Apr. 2009 (UTC)
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/ 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.)
services/ clock/... cron/... dns/... dyndns/... httpd/... ntp/... jabber/... snmp/... stella/... pwm/... tftp/...
- 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)
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
- 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)