On Sat, 2009-06-13 at 01:46 -0700, David Brownell wrote:
> On Saturday 13 June 2009, Zach Welch wrote:
> > On Fri, 2009-06-12 at 21:42 -0700, David Brownell wrote:
> > > Doc update: say "jtag newtap ... -disable" records the
> > > state after exiting the RESET state, matching the only
> > > implementation we're working with so far (TI ICEpick-C).
> > >
> > > Matching code updates, including a few minor cleanups
> > > mostly related to the JTAG event callback mechanism:
> > >
> > > - a memory leak in jtag_tap_free()
> > > - fix conceptual bug in unregistering JTAG event callbacks
> > > - remove hidden assumption about JTAG event numbering
> > > - move function declarations to the header where they belong
> > > - some end'o'line whitespace
> > >
> > > Now we're sure the "enable" flag value is correct after resets.
> >
> > Why did you move the declarations of jtag_tap_{init,free} to the bottom
> > of jtag.h?
>
> Lack of reason to put them anywhere else in that file. They
> clearly didn't belong as externs in that ".c" file, though.
Better than exposing them in a public API. I had thought about adding
jtag/core.h to export internal JTAG module symbols like this; I think
there may be other bits of the jtag.h file that could be moved in there.
> > Also, would it be too much to ask to separate your changes into slightly
> > smaller pieces?
>
> No problem. This is the patch where I would have expected pushback
> on that point. ;)
Heh. I'm not perfect either; my recent work in these files and these
suggestions to improve it made me ask. :)
> I *am* however hoping to get some feedback from folk who have had
> their Beagles working, to whatever degree, with previous stuff.
> And "try out this series of a dozen patches" is a losing game.
> Three ... is doable.
If there are reports from others that these patches solves problems, we
should try to push some flavor of them into 0.2.0. Still, I would like
to see the functionality from the first two patches layered properly.
> > Plus, you will motivate me to finish the "import series from e-mail"
> > portions of my patch handling scripts, if you start producing series of
> > patches with a dozen patches each. Or do you think my recent practices
> > have taken this idea too far?
>
> You mean, checking in lots of patches without posting them to the
> list even as an FYI?
Ouch.
The openocd-svn list provides ongoing notification of the changes.
Posting direct commits here seems redundant to me. Heck, I think that
even the "committed" messages are pedantic for this same reason, but I
do that out of tradition. If you want to know that new patches have
been committed, you can use 'svn log' or subscribe to that mailing list.
I committed these changes directly because they have not included any
apparent functional changes. Except for scripts with syntax errors,
your patches from the same period have made more visible changes to the
system than all mine put together (from what I recall).
Before I started committing this work, I considered the possibility of
posting each series of patches, but I did not feel they deserved that
much attention. My recent patches have been intentionally trivial, so
they should be easy to review and bisect. As far as I can remember,
nothing new or experimental has gone in during this work that affects
the operational code paths.
There have been very few reports of regressions after two weeks of my
heavy patching, and I imagine that it has not been for lack of looking
on the part of other maintainers and contributors -- if only to call me
out in a similar fashion. The complete lack of community discouragement
has been interpreted as ongoing success and reason to continue unabated.
Your sentiment is the first to indicate a clearly contrary opinion.
Since it has been _so_ easy to get flamed here in the past, I figured
that any minor sparks would result in my getting incinerated to a crisp.
Nothing until this latest comment, though I hope that this response
demonstrates my hypersensitivity to such reproach.
I have a couple of dozen meta-patches prepared to clean up most of the
remaining whitespace and core type issues in the tree. I also would
like to create another series of patches to address the dozens of API
naming issues and other remaining mechanically resolvable problems.
Another valgrind-exposed "fix" to clear all allocated register buffers
negatively affects performance, though I implemented it such that it can
be optimized away for release. I expect all such changes to be resisted
due to its impact on the tree or build, but -- let me be clear -- I
would never commit such patches without the community's consideration.
Those things deserve review and comments -- not mundane clean-up. While
my recent efforts have started to take out some of the trash, the amount
of work that remains to be done daunts me, and I think literally
hundreds of patches will be required to address all of the issues in the
incremental fashion that I have been taking. I am not exaggerating.
Altogether, your reply has drained my enthusiasm to continue with this
line of work; I must assume that others share your sentiment but have
not said anything.
Thanks,
Zach
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
