Code Restrukturierung - 2009

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.c
 	portio/
 		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)