|
|
| (12 dazwischenliegende Versionen von 3 Benutzern werden nicht angezeigt) |
| Zeile 1: |
Zeile 1: |
| − | == 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)[[Benutzer:Rayofhope|Rayofhope]]
| |
| | | | |
| − | === 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 einem "build" Verzeichnis zusammenfassen?
| |
| − | * Keine Ahnung wofür das hier da ist: ipchair
| |
| − | ** ipchair ist ein einfacher Paketfilter im Stile von iptables, deswegen auch der Name ;-)
| |
| − | ** <strike>gehört meines Erachtens dann unter core/</strike> --[[Benutzer:Stesie|stesie]] 05:52, 7. Apr. 2009 (UTC)
| |
| − | *** ok --13:17, 7. Apr. 2009 (UTC)[[Benutzer:Rayofhope|Rayofhope]]
| |
| − | *** wenn wir uns darauf einigen, dass uip unter protocols soll, ist ipchair unter core auch falsch aufgehoben. wir könnten es auch unter protocols/uip/ipchair/ packen --[[Benutzer:Stesie|stesie]] 14:32, 8. Apr. 2009 (UTC)
| |
| − | **** ja, sehe ich auch so [[Benutzer:Rayofhope|Rayofhope]] 15:40, 8. Apr. 2009 (UTC)
| |
| − | * Sollte crypto evtl nach core? Sowohl Anwendungen/Services als auch Protokolle sollten davon gebrauch machen können. Um das zu symbolisieren, könnte sich der core Ordner anbieten. [[Benutzer:Rayofhope|Rayofhope]] 15:40, 8. Apr. 2009 (UTC)
| |
| − | ** jap --[[Benutzer:Stesie|stesie]] 15:57, 8. Apr. 2009 (UTC)
| |
| − | * vfs sollten wir meines Erachtens auch aufspalten, habe ich mit vfs_sd ja schon begonnen.
| |
| − | ** das vfs-core würde ich nach core/vfs tun, ebenso wie das vfs_inline
| |
| − | ** die Frage ist wo wir die embed/ Seiten hinwerfen.
| |
| − |
| |
| − | === 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)
| |
| − | <strike>pinning.c</strike>
| |
| − | portio/
| |
| − | <strike>watchcat/...</strike>
| |
| − | 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. --[[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)[[Benutzer:Rayofhope|Rayofhope]]
| |
| − | * 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)[[Benutzer:Rayofhope|Rayofhope]]
| |
| − |
| |
| − | === 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/...
| |
| − | zbus/
| |
| − |
| |
| − | === Protocols ===
| |
| − | protocols/
| |
| − | uip/... (inkl. ipv6.c)
| |
| − | usb/...
| |
| − | <strike>zbus/...</strike>
| |
| − | yport/...
| |
| − | bootp/...
| |
| − | mysql/...
| |
| − | modbus/...
| |
| − | <strike>mdns_sd/...</strike>
| |
| − | dns/
| |
| − | 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. --[[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 bzw nutzen, sondern diese Protokolle nur per software nachbauen, daher wäre ich eher tendenziell für den Ordner "protocols" --[[Benutzer:Rayofhope|Rayofhope]] 12:22, 8. Apr. 2009 (UTC)
| |
| − | ** hmm, ok
| |
| − | * zbus, yport, modbus ist auch so eine Sache, also mit fließender Grenze hin zur Hardware. rfm12 haben wir bspw. unter hardware, und nur da gehört es meines Erachtens hin. ZBus geht eigentlich in die selbe Richtung, das ist ein Bus zum Vernetzen mehrerer Ethersex über längere Strecken hinweg. Ok, yport und modbus sind, so viel ich weiß, TCP<->Serial gateways, von daher sind die unter protocols wohl ganz gut aufgehoben.
| |
| − | ** ok, über zbus sollte man dann noch einmal nachdenken. Ich habe rein nach Namen einsortiert und wusste nicht, was zbus leisten soll. Einerseits steuern wir mit diesem Modul andere Hardware an (andere ethersex's), anderseits wird in dem Modul das Protokoll definiert um genau dies zu erreichen. [[Benutzer:Rayofhope|Rayofhope]] 15:49, 8. Apr. 2009 (UTC)
| |
| − | * mdns_sd würde ich vom Gefühl eher unter services/ erwarten. Das ist zwar nicht unmittelbar eine Anwendung mit der man sprechen kann, aber es benennt die eingerichteten Applikationen im Netz (Avahi). Eher würde ich da dns/ noch nach protocols/ holen als mdns_sd in protocols lassen. --[[Benutzer:Stesie|stesie]] 14:32, 8. Apr. 2009 (UTC)
| |
| − | ** mdns_sd würde ich in diesem Falle in avahi umbennenen. Zumindest mir sagt das dann mehr. Abgesehen davon hast du wohl recht, dass gehört eher unter services. [[Benutzer:Rayofhope|Rayofhope]] 15:49, 8. Apr. 2009 (UTC)
| |
| − | ** dns sollte nach protocolls. Habs beim einsortieren mit einem dns daemon verwechselt. [[Benutzer:Rayofhope|Rayofhope]] 15:49, 8. Apr. 2009 (UTC)
| |
| − |
| |
| − | === Services aka Applications ===
| |
| − | services/
| |
| − | avahi/ (jetzt mdns_sd)
| |
| − | clock/...
| |
| − | cron/...
| |
| − | <strike>dns/...</strike>
| |
| − | 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. [[Benutzer:Rayofhope|Rayofhope]]
| |
| − | * zugegeben, wir sollten gegen die vielen #ifdef vorgehen, aber alle wirst du nicht aus core/ rausbekommen
| |
| − | ** Hab mir das fogendermaßen gedacht: Ein Modul fordert eine Initalisierung oder einen regelmäßigen Aufruf des periodic Timers an, indem es im eigenen Modul Verzeichnis beispielsweise eine normale Text oder m4 Datei mit dem Hinweis auf die Zielfunktion bereitstellt. Irgendein Buildscript sammelt von allen Zielmodulen diese Einträge und erstellt eine Init.c, periodic_tasks.c Datei oder so. Mal sehen. [[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)
| |
