On Wed, May 9, 2012 at 7:16 AM, Andreas Fritiofson <[email protected]> wrote: > On Tue, May 8, 2012 at 11:28 PM, Peter Stuge <[email protected]> wrote: >> Jean-Christophe PLAGNIOL-VILLARD wrote: >>> I think it's time to do a new release >>> this friday the merge window close >>> Attention I'll close arround 8pm Shanghai Time >>> follwing by 4 weeks of rc >> >> I disagree with this.. >> >> From Tuesday to Friday is simply not reasonable for the volunteer >> efforts that are ongoing and in some cases have been ongoing for a >> long time to produce some sort of results. > > Agree that this is a bit short notice, a week more would have been > better. But it's high time for a release.
I agree that it is high time for a release. But the merge window closes too soon. One more week is certainly better. Maybe two weeks are even better. >> Personally I have three items of high interest which I would like to >> see in the next release, in no particular order: >> >> 1. Efforts by Tomek and Simon toward SWD >> 2. Cleaning up the total mess regarding libusb-1.0 in OpenOCD >> 3. Andreas' new FTDI MPSSE driver 4. One more items would be Spencer's ST-Link patch. >> 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 > 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. I agree. >> 2. and 3. go partly hand-in-hand, since mpsse uses libusb-1.0. > > Don't mix them up. MPSSE is in gerrit and waiting *now* and uses the > configure framework that's currently in place for libusb-1.0. Fixing > that framework is a totally separate issue, which requires at maximum > a single line change of the header file path in MPSSE, once the fix is > in place, regardless of the type of fix. Needlessly serializing > development is a bad idea. > >> One approach for 2. is to revert the use of libusb-1.0 in OpenOCD >> completely, which affects the jlink, osbdm and stlink_usb drivers. I do not think this is necessary. They are no worse than using the old driver in reality. It also complicates merging Spencer's stlink patches which will be an important for the 0.6 release. >> Another is to try to patch up the code so that it is at least not >> an absolute mess. The latter requires significantly more effort. It can be done later. > I started a branch to clean it up, before I realized I needed the > async api which made it completely unusable anyway. That is indeed true if you want to gain performance. The other alternative approach to your mpsse patch is to convert libftdi 0.1x --> libftdi-1.x, but again async API needs to be used. Without using async API, performance gain can not be achieved with libusb-1.0 or libftdi-1.0. That being said, we can consider the conversion to be the first step toward libusb-1.0. > 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. It is actually not the same API, but rather using sync API of libusb-1.0 does not make much difference of using libusb-0.1 API (all sync API). That being said, again, I would say this can be considered as a first step towards converting to async API. >> After reverting, mpsse could be added along with somehow clean >> libusb-1.0 support in the build system, and libusb-1.0 would not >> be used by any other code. > > Don't let the revert and/or fix hold off an unrelated patchset. Even > the abstraction and the build system are separate issues. The > abstraction may be flawed, but the autotools support is not worse than > what we've had before, for example for libftdi. The lack of pkg-config > is an inconvenience. I agree that it is not worse than before. The pkg-config issue has always been there and can be fixed later. >> The USB abstraction needs fixing real bad, I don't think it's >> something we want to release. I urge you to have a look at it >> Jean-Christophe, ideally along with the review I provided which >> was unaddressed before the code was merged. > > I agree that it's an ugly mess but not that it's a huge problem that > could hold off a release. If we get a patch to fix it in time, great. > Otherwise, no big deal, we'll fix it until 0.8.0. We're not promising > to keep it for all eternity just because it's been part of a release. I agree. I think (3) and (4) are good to have. As for (2), let us fix it later, it is not as Peter sounds in reality. As for (1), again more discussions and testing are needed. -- Xiaofan ------------------------------------------------------------------------------ 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
