Ok, it's been a few days and things are slowing down in the thread
referred to in the subject line.
I'm trying to assemble a checklist of changes (if any) that I need to
make to the patch before it can be accepted. I am assembling this list
by running down the previous replies in that thread.
It was this or simply reply to my original message. Right or wrong, I
ended up going with this. So anyway, I'll get on with it. The
following are things from the thread that might stand in the way of the
patch being applied. Most of them seem to be just renaming/moving
things. Some have already been addressed in my local copy as indicated,
and a new patch could be submitted which includes those changes.
1) Spencer Oliver's concern about legal implications. If this is a
problem, nothing below matters. It is one vote (or not even a vote, so
much as voicing of a possible concern, I can't say), but it only takes one
vote to make something not unanimous. I don't know how such things work
in this particular organization. The law appears to be on our side
here, judging from what I and others have read, but none of us are
lawyers. I would be extremely surprised if Raisonance were to be of any
help. They seem to be trapped in the '90s. There doesn't seem to be
anything I can do to the patch that would address this.
Is this going to stop the show or not?
2) I have gone ahead and arranged to compile speed_table.c to a .o and
link that in. Because the symbol was no longer static, I prepended
rlink_ to it. Because of #3, I also renamed speed_table.c to
rlink_speed_table.c and I renamed the .pl script accordingly. I could
have just renamed the .c file to .h, instead of doing all that, but this
wasn't too bad, and is good for future-proofing.
3) I have moved rlink.c into the rlink directory. This was, in fact, as
simple as changing rlink.c to rlink/rlink.c in Makefile.am in
src/jtag (and moving the file, of course). The .o file still gets
created in the src/jtag directory,
however, and it is for that reason that I had to rename speed_table.c to
rlink_speed_table.c, since it creates rlink_speed_table.o in src/jtag.
4) Removed patch creation targets from the Makefile in the rlink
subdirectory.
5) Keeping rlink_speed_table.c prebuilt is deemed
fine, so no change needed there. There was discussion of having a
separate area (eg: trunk/tools/{toolname}) for tools to do
the prebuilding ("maintainer-mode" or "super-maintainer-mode").
What is not clear is how critical that is to acceptance of this patch.
That may be cleared up in a reply to that email, though.
It seemed like a good idea for the future,
but it would affect a number of drivers, most of which I do not control
or even necessarily understand. I could just unilaterally start putting
stuff in tools/{toolname}, but that's going to be pretty goofy if nobody
else does it. So is this a requirement or not? The
rlink part of that could, of course, be changed when all the others are,
later on, when such a thing gets instituted.
6) Have I forgotten anything?
7) #1 makes everything else unimportant if it is going to be a problem.
_______________________________________________
Openocd-development mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/openocd-development
