Hi all,
This message follows my sentiments about the human side of OpenOCD with
a more technically focused perspective.
First off: if you had conflicts that prevent a clean 'svn diff' patch,
you should be able to copy your original pre-merged files (the .mine
files) into a fresh working copy of the older revision (along with
changes to any other files that did merge okay) and extract the clean
patch therein. Let me know if this advice is not as helpful as I think
it should be; if all else fails, send me your entire working copy and I
will deal with the mess that I caused.
Anyway, here is my current list of outstanding tasks, where '+' items
have a current patch and '-' items do not. This is not a milestone task
list; I am leaving that as someone else's responsibility.
* FT2232 driver:
+ integrate FTD2XX High-Speed Device Patch (Joern Kaipf + ZW)
+? remove non-A types (Uwe Hermann) (does this patch still apply?)
- fix segfault from long scan chains (observed by Dick Hollenbeck)
- fix non-recoverability of cable connect/reconnect
- cure buggy madness (others might try to break this into pieces)
* J-Link driver (w/ yellow hardware)
- integrate Jeff and Duane's pending changes
- cure buggy madness (this is my own poorly qualified TODO item)
- test on known targets
* MC1322x target support
- integrate and test support from Jeff and Duane
- get working with a known good interface (i.e. not today's jlink)
* TAP changes:
- use tap_set_state everywhere to allow logging TAP state transitions
- add new TAP state table provided by Jeff Williams
- update tap_get_tms_path API as suggested by Duane Ellis
- slow boat: add tap_get_tms_path2 and allow both for a while
- convert drivers that use old API over to the new one
- remove old tap_get_tms_path
- other changes work picking out of Jeff/Duane's patches
* CFI:
- factor vendor-specific code into separate source files
- investigate adding new interface to those bits?
* Architectural Upgrades
- Allow N:M:P mapping of servers, targets, and interfaces
* ARM:
- better alignment with ARM technical documentation (Jeff W.)
* Miscellaneous:
- continue to improve state and system debugging (Jeff W.)
- overhaul use of types to improve 32/64-bit portability
- factor drivers to improve re-use
If I do not include something important to you, it was not intentional;
simply follow-up with a your items and I will add them to the next
version. I am not interested in keep track of what goes in (the repo
log does that), so I will simply drop items when that happens for them.
I hope that -- by maintaining this list and posting it here -- everyone
will take away the idea that I care about the project's architecture.
I seriously considered writing a competing implementation, because I
_knew_ there would be this kind of resistance to change.
I see the potential massive changes that would benefit the system, such
as the list item for OpenOCD to allow heterogeneous configurations of
servers, targets, and interfaces (N:M:P). Admittedly, this was
suggested by others recently (though I can't find the exact thread at
the moment), but it is the kind of task that I might find entertaining.
I see other potential in the code, but I still have not been able to get
my head around the nature of everything needs to be done. There a lot.
If I could afford to play in this sandbox at this level of intensity
indefinitely, I could help make those visions real, but -- even if that
was fiscally and physically feasible -- that process would take a lot of
trust and courage on the part of the community. Still, it doesn't
matter who actually makes those changes; they will be painful, but the
metaphor of surgery is apt. We must cut to cure.
That will result in a slow-but-steady flow of incremental patches, which
would add up to a lot of churn. As I am but a babe in the woods around
here, I will not presume to know what is best for this project, but I
know a thing or two about what it takes to produce software. If we want
to reach for big goals, pain will be all but unavoidable.
I present this plan in the hope it can ratified by the community to help
us move forward on the same page. Reaching a meaningful 1.0 will
require commitment to making multitudes of the sort of changes that I
have started. Dealing with merging and conflicts is a necessary evil of
working with open source; the only cure is to publish your patches first
and get them into the tree. I haven't had a conflict all week. ;) :)
Cheers,
Zach
_______________________________________________
Openocd-development mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/openocd-development
