Hi Tomek,
it's great that your focusing on functionality. Cracking the
technical problems and making a patch series that's right
for OpenOCD are two hard problems. Perhaps better
attack one at the time?
One hard thing about SWD is to crack the technical problems,
the other hard thing is to create a series of patches where
as many as possible of the list are able to follow what was
done to OpenOCD. This is crucial as otherwise you would
be the only one able to modify the code, at which point the
value of your patches would drop sharply.
Your contributions to OpenOCD can never be greater than
that of one man, but if you enable the rest of the community
to work on SWD then you have reached another level entirely.
There is an optimal size of git patches where the maximum number
of people are able to follow what was done to the code. That's
the size we should aim for. Generally this means small patches with
one change per commit.
Note that with interactive git rebase you can create the
history after you have the solution.
At this point, I think we're ready to accept the first commit,
which would do the following:
-creation of src/transport directory for transport layer
-creation of src/interface directory for interface layer
-moving transport.{c,h} from src/jtag into src/transport and updating
the headers and Makefile.am
You can then rebase your work on top openocd master and
your next commit would be much smaller.
--
Øyvind Harboe
Can Zylin Consulting help on your project?
US toll free 1-866-980-3434 / International +47 51 87 40 27
http://www.zylin.com/zy1000.html
ARM7 ARM9 ARM11 XScale Cortex
JTAG debugger and flash programmer
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
