Andreas Fritiofson wrote: > > By 1. I do not mean that next release must support SWD, but I do mean > > that openocd.git must have developed in an agreed-upon direction. > > Simon and Tomek have both put a lot of effort into this and I want to > > see some of that go into the release, even if there is more work to > > come. > > There will be more releases to come. Since we haven't even fully > agreed upon a direction yet I find it highly unlikely that anything > usable SWD-wise will get into mainline before we need to cut 0.7.0. I > don't think we should hold off 0.7.0 indefinitely to wait for SWD.
I tried to clarify that I expect neither of these things for the next release. I do want us to have *something* however. It does not need to be visible, but it should be there. > I also disapprove of merging any incomplete framework changes that > could turn out to become legacy once the proper solution is in > place. And I'm certain we will need a fair amount of framework > changes to accommodate a clean SWD implementation. As for how to realize SWD I will prefer taking many small steps, as long as they are roughly in the right direction. It does not have to be a perfectly straight line from the start, as long as it is generally in the right direction. > > 2. and 3. go partly hand-in-hand, since mpsse uses libusb-1.0. > > Don't mix them up. I do not. That's why I wrote "partly". > Fixing that framework is a totally separate issue, Yes, as I wrote. > Needlessly serializing development is a bad idea. I never suggested that. If I am unclear then please just ask me to clarify. > I started a branch to clean it up, before I realized I needed the > async api which made it completely unusable anyway. I don't quite > understand the purpose of the abstraction, it's not very useful. > If you want to use libusb-1.0 with the same API as before, there's > always libusb-compat. Yes, but I think the motivation was to cut the extra dependency and go straight to the 1.0 API. You're right that the abstraction isn't super useful beyond that it allows OpenOCD to build with whatever libusb API is available on the system. Especially for Windows this is nice, because libusb0.sys and libusb-win32 is more flexible (0.1 API) than WinUSB.sys (1.0 API). > Don't let the revert and/or fix hold off an unrelated patchset. Stop repeating this. > Even the abstraction and the build system are separate issues. Yes and no. All the problems were added by a single patch. > the autotools support is not worse than what we've had before, > for example for libftdi. That's not a reason to have bad code. You didn't push half a buggy driver, you finished it and pushed something good. > I agree that it's an ugly mess but not that it's a huge problem > that could hold off a release. I expect more people to see the release than .git, and publishing a release which potentially has *more* issues than the previous one is stupid imo. > If we get a patch to fix it in time, great. You know just as well as I do that the only patch for this that "we" will get will have to come from me, since noone else seems to really care much about it. //Peter ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ OpenOCD-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openocd-devel
