Freddie Chopin wrote: > So we have two "don't-s" and no "do-s" - just like with SWD - > everyone knows what is the wrong approach
That's silly. If everyone knew what approach is wrong then those suggestions would never have been posted to the list in the first place. > no one shares info how would a good one look like Does anyone seriously believe that someone has some info that they are purposely *not* sharing? That doesn't make sense. I guess it is obvious to everyone that doing (re)design work takes a lot more effort than analyzing any one design proposal. Everyone has little time, so it is not very realistic to expect a counterproposal just some weeks after a proposal which took months (years?) to design and implement. It is however very easy to spot problems in a given proposal. It would have been just as easy to spot the same problems if the proposal was first described and discussed, before it was actually implemented. > the info that "first OpenOCD should be redesigned" is worthless > without info on how it should be done (to not be rejected after > year of work), isn't it? Of course it's not worthless, it coarsely points a direction. It is of course not pointing an *exact* direction. The exact direction will be the result of (re)design work, which is again not trivial, and which I hope will be a community effort rather than something expected to be pushed down into the project from whoever happens to be able to give commits +2 in Gerrit and include them in openocd.git. It is very valuable to have developers with different skill levels do design work together. More experienced developers have witnessed what is good and bad given various requirements and can very efficiently transfer that knowledge to less experienced developers, who on the other hand can easily contribute fresh perspectives. > I guess it's official now - OpenOCD is NEVER* going to have SWD support Now who is complaining? Come on - of course SWD is desirable, but certainly not at any cost. There is already a critical mass of flaws in OpenOCD, which should be dealt with at any opportunity possible. SWD very much presents a compelling such opportunity. Andreas' MPSSE driver is an excellent initiative to fix one big flaw. Notice that it hasn't even become the default driver for those interfaces yet, so obviously the project as a whole is not very fast at fixing flaws. It must be a priority anyway. > BTW - sorry to ask - does "ST-link interface as a target" with it's > duplicated config files for targets is OK for this "nothing but perfect" > approach? I guess it's a hack too, with lot's of code duplication Why would it be any more OK? It is certainly a hack. You know very well that I'm extremely unhappy also with some of Spencer's changes, and I'm extremely happy with some others by him as well as you and Tomek. (Remember the libusb1 stuff which still has not been fixed. I spent significant time on feedback for those changes, to finally find that feedback wasn't considered before including the code, and somehow everyone expects me to fix it because apparently I'm the only one who understands why there is a problem in spite of documenting it in my feedback. Guess if I'm excited about doing that.) > yet hundreds of OpenOCD users are happily using it (me included)... > Adding SWD would no doubt make that people miserable and furious. Think of the children^users. > I've also got one smart-ass comment about Peter's opinion that FOSS is > perfect and commercial software is crap: > http://en.wikipedia.org/wiki/Usage_share_of_operating_systems > How's that possible that the most perfect FOSS in the world appeals to > just 1% of population, and the other 99% prefer crap? CrossWorks has SWD > over FTx232 based adapters. And it works. And I guess no one using it > cares whether it's a perfect solution or a dirty hack as long as it gets > the job done (which it obviously does). Of course noone cares, because they are merely consuming a product. If that's what you want to do that's fine, but don't confuse it with open source. Companies like Red Hat and Canonical work really hard to make consumer products out of open source. OpenOCD is nowhere near that level of product. If you want to make that happen then you have to do what Red Hat and Canonical do - hire some brilliant developers. I for one do want a usable tool, but I also want to understand the tool, and to be able to control and adapt it to work exactly the way that fits best for me. If I work on open source then as a bonus I can potentially amplify my work many thousand times, and benefit others with similar problems as mine, all around the world. > Users of OpenOCD don't really care They don't have to care about anything. They should use whatever tool fits them best. If they find that in the end they actually do care about OpenOCD then it would be great if they come back and help out with things like testing proof-of-concept changes, or participating in design discussions (user interface also needs design, every user can help with that) or pay some developer they know to code, or *gasp* code something themselves. > they just know that it does not support SWD and it's been enough > time for it to implement that... Do you realise that you are trying to guilt every OpenOCD contributor because the project does not yet satisfy an arbitrary user need? That's really exceedingly poor form Freddie, and quite destructive for the mood of all contributors. What's up with that? "it's been enough time" - sheesh.. If it has been enough time then how come you have not yet produced commits which are already included in openocd.git? Since you haven't, I guess there actually *hasn't* been enough time yet. Do not project your expectations onto others. That's not cool in open source, or in any other environment for that matter. If you want something done, work on it yourself, rather than saying that others should have already finished it. > What's the purpose of OpenOCD - being an example of "perfect" > software or being an usable and versatile tool for debugging? The original purpose was to make Dominik graduate. What is important for a bridge over a river? Perfect build quality or fast construction at the cost of much more maintenance? Both can have merits, I am however a firm believer that build quality has a much greater value in the mid to long term. I don't like the throw-away culture of our times. It's not like OpenOCD is the only bridge over the SWD river, and it's not like there are thousands of people wanting to cross the river while eagerly giving a hand with the construction. I agree completely with you, Tomek and Andreas about making a plan for SWD, but again, that's not neccessarily something we accomplish in a single email, or even ten. > I think some of people on this list just don't care about the > latter and are striving only for the former... I believe that software quality makes a tool more reliable, which is important for me, not to mention that I think it makes the tool several orders of magnitude more versatile. Someone who just wants to cross the bridge to sell milk on the other side doesn't care *how* they cross of course. They can either help out with testing of Tomek's proof-of-concept and at the risk of some wasted time and effort kill two birds with one stone, or they can choose not to care about OpenOCD and Tomek's work and consume a product that will get them to where they want to go. I don't care what they choose. CeDeROM wrote: > some guys sit on the code that was not perfect Define "sit on" ? The code is published in several places and can be tried by anyone. I'm confused? > complain that its not perfect Oh noes. Better not point out any problems with anything. Ever. Did you read the children's story "The Emperor's New Clothes" ? I am *not* saying that libswd is naked. I have not said anything concretely about the commits besides that ft2232 is a dead end. Of course I will look at the code before I can say anything specific. > propose nothing concrete What? Spencer is even reworking your code, in order to more clearly see what can be proposed. > don't accept any change except one line patches on what already in > there. I guess this refers to my desire for minimum logical changes, and I'm afraid that you have misunderstood what I mean, even though I tried to explain with an example and wrote explicitly that number of changed lines has nothing to do with it. Some commits will certainly be only one line changes, and there may be many of those, which lead up to some other change with huge number of lines changed, while still changing only a single thing logically. > you know best what is inside OpenOCD like noone else, also you know > what and how to fix things.. This is also a misunderstanding. I know very few parts of OpenOCD "like noone else" and I do not know how to fix everything that is wrong. I have seen a handful-or-so problems in the code, but I certainly do not have a full picture. I guess that the same may be true for every other contributor. Don't you realise that this is why good commit message are so important? When I work on some part of the code which noone else knows about I will learn about that code and the code nearby, so I am in a better position than anyone else to educate everyone else about that area, in some way that makes sense. If I knew what and how then I would already have said so. It's very easy to identify problems without knowing the best solution, and identifying problems is still valuable. > You don't want to discuss the changes Of course I do, but because the changes are functionally large such discussion requires non-trivial effort. Very simple issues (like extending ft2232 instead of using mpsse) are obviously much quicker to notice and to mention. > If we really don't get any consensus, it will be necessary to fork > the project I guess Don't you realise that you already did that when you said that you do not want to change your code? Freddie Chopin wrote: > I don't know what's a step backward here? > SWD support in general? Certainly not. It's something that would be useful for many. > Extending jtag_interface? Quite possibly, yes. I do not know anything about what is inside jtag_interface, but merely from looking at the name it is immediately clear that this construct is absolutely unsuitable for SWD. It's obvious that jtag_interface needs to be split into two parts. How? I can't say anything about that without looking closer. > Doing anything in ft2232.c? Absolutely a step backward. It's a waste of time given the MPSSE driver. > Using LibSWD? Certainly not a step backward. I'm completely sure that OpenOCD can benefit from using LibSWD (is it capitalized like that Tomek?) but like Andreas pointed out: it makes no sense for OpenOCD to model SWD exactly the way that LibSWD does it just because LibSWD exists. > Yes, the architecture of OpenOCD is broken, JTAG-centric or > whatever you call it. There are people that would be willing to > improve that - just need some guidance and a plan, which could be > used to partition the job among many people. Unless those "people" (who are they?) can also work together with others on the plans, it's quite possible that the bridge over the river SWD will be rather unmaintainable. > Just try to be objective - there's the topic by Tomek, there are > absolutely NO constructive messages there, right? No, not yet. It's not a small topic; significant contributions require significant effort. The libusb1 review was also significant effort. > the "right approach" (discuss first, ...) doesn't seem to be > working either... I think you need to give it some time. But having a developer meeting would also be helpful! FOSDEM is coming up - who will be there? > we need a plan .. > this should be a group's effort to create a plan and partition it > among volunteers A plan is already being worked on. Like you, I also think that everyone who wants to help the project should study the code and contribute to the reorganization thread. It's a very important topic. > Does a 33% drop mean that current policies are good or bad for the > project in long term? Your argument is that number of commits is more important than anything else, and you suggest that a large number of commits by definition is a good thing for the long term. That makes no sense whatsoever to me. Don't confuse quantity with quality. > Isn't it the case where we should do one step back to let some > fresh air to the project, even at the price of going in > "not-perfect-direction" for a moment? Why should we settle for anything less than going in the right direction? That makes no sense to me. > I'm just saying that in case of something as important (essential!) > for OpenOCD as SWD we should all cooperate to have it as soon as > possible, even without proper SWD is completely irrelevant for a large chunk of OpenOCD users working with the high-end parts that OpenOCD supports, the girls and guys who run OpenOCD to debug Linux and the like. I guess you agree that for them it is rather essential to have fewer flaws in OpenOCD, not to have more new flaws because of restrictions by older ones. > it's past reasonable time for that to appear anyway... Stop with the guilting. It's really unacceptable. If the tool does not fit you then pick another tool. You and everyone else are not paying for developers working on OpenOCD to do SWD so how can you think that it is OK to guilt someone else because they aren't giving you what you want? > is OpenOCD being developed for users or for software perfection? The time I spend on OpenOCD I want to spend on making it better. What of all the values of "better" that I feel like working on at any given time can of course be different.. I'm happy when users can benefit from my work, but I am surprised that you don't already realise that all open source contributions happen exclusively based on what contributors want to do, and that this is also why open source can be so successful - when contributors want the same thing. In small projects like OpenOCD it's very easy for everyone to want different things, and having different backgrounds makes it even easier to want directly opposite things. I hope that everyone genuinely understands my point with the negative vs. positive software development spiral. If we make the software better it becomes easier to make further improvements. If we make the software worse on the inside then it becomes ever more difficult to make any improvement whatsoever, and all time will go to working around internal problems, until at some point someone rewrites the whole thing. I like starting over when that is called for, but I don't like the negative software spiral when it's so easy to work in the positive spiral instead. //Peter ------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnnow-d2d _______________________________________________ OpenOCD-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openocd-devel
