Le 17.01.2013 19:39, Peter Stuge a écrit : > Spencer Oliver wrote: >> i am also after a second opinion on some of the changes, mainly >> effecting the transport and additional jtag_interface for swd >> (ft2232_swd). > I can not understand why we would want to add *any* code to > openocd.git which depends on the horribly crappy ft2232 driver > instead of taking advantage of the far superior mpsse driver. To have a starting point. > That alone is more than enough reason to say that these commits > should not be merged. Wrong. The FT2232.c helped Tomek to have an easy starting point to dev his higher level. If the mpsse was here before he started his job, he maybe selected this one or not.
Why was OpenOCD growing quickly ? Because the ft2232.c coupled with d2xx driver was stable enough. Please evaluate the work of Tomek instead to just say "NO" since it use ft2232.c as first steps. > > Tomek CEDRO wrote: >> The problem is the layout > So fix this layout problem *first* with one minimal commit, before > doing anything else. > > >> creating additional interface. This was the most elegant solution I >> could think of with no bigger internals reorganization. This is why I >> want to get into internals reorganization right now... and you can >> test the SWD functionalities meanwhile :-) > Completely backwards. > > >> Also again I dont want to rebase a lot my commits because that would >> destroy changes order. > That makes no sense. Rebase does not change order unless you tell it > to. Please read git rebase documentation (the first page of man > git-rebase under DESCRIPTION is more than enough) and feel free to > ask on this list if you have any questions. > > >> To start the next step (internals reorganization) I need to have my >> commits included > I think it sounds like it needs to be the other way around. And I > can't say that I'm surprised. > > >> this is why I prefer to work on a local fork and new branch not to >> mess with the current relase line... > It's a fundamentally broken workflow. You need to make small changes > to current master in order for anyone to be able to consider them. > > Anything else is basically outdated code. > > Multi-billion companies have used your approach for their work on the > Linux kernel and all they get for it is ridicule by everyone with > half a clue in the kernel community. bla bla bla . You cannot compare Linux and OpenOCD. Linux is now mature and it is natural to have only small patches in the kernel. But what about the begin of Linux ? I am not sure there were only small patches. Sure small patch is ever better but sometimes not possible. > Fortunately many of those companies have learned the lesson and are > working within the kernel community now, in order to not waste their > engineering time. I hope you'll follow their lead for OpenOCD. > The better way to learn is to do something, to have troubles, and to correct them. You know what I mean regarding libusb-0 issue. > CeDeROM wrote: >> Having Bitbang at TCL level also allows to write more sophisticated >> TCL scripts for various protocols that are not (yet) suppoted at >> source code level :-) > Bitbanging is never a good idea. The only time it has the slightest > chance of even working is if the IO register is very very close to > the code that implements the logic. Consider a USB interface driven > by high-level scripting and you find the very antithesis. It's a > horrible idea. depending on what the end-user is doing. Sometimes it could help to do a specific actions... I mean cjtag spi hacks. But you are right it should not be used in the concept itself. > > Freddie Chopin wrote: >> we already do have two sets of files for most of adapters - one >> for ft2232.c and another one for ftdi.c... > How can it seem like a good idea to add *another* set of files? > That's just insane. I think the sane approach is to simply delete > ft2232.c and move on. It sounds like Tomek already has ideas about > how to use mpsse.c which is great! > > >>> To me the point of gerrit is to merge a working change, not >>> something that is wip. >> Yes, that would be nice > Why should we settle for "that would be nice" as opposed to > "that is how we work" ? > > >> but it's also true that SWD is a DRASTIC change and a >> "completely working and polished solution" would be like 100 >> commits with thousands of lines... > So what? That is absolutely no justification for blindly merging > whatever commits in whatever state without crazy careful review. > > We collectively want to *improve* OpenOCD, I believe. Taking one > small step back in order to take two steps forward is sometimes > worthwhile. Making a "DRASTIC" bad change just because it exists > is hardly helpful. > > >> I guess such reorganization or source code would take at least >> a few months if not a couple of years > Certainly if it all has to be rewritten in C++. But I guess that > everyone understands that if commits are absolutely minimal and > change only *a single thing* then they are also easy to review, > even if they change this one thing in many places. > > Make many small commits to fix things up, then SWD is easy to add. > > >> Merging the code as it is now will probably be a nice boost both for Tomek > And it will be demotivational as hell for everyone else who has to > deal with a "DRASTIC" change being forced into the codebase. > > >> and for other developers as it would be easier for them to also >> implement/change/improve something. > What? It's quite the opposite. Or do you mean that it's easier to fix > something in openocd.git cloned from repo.or.cz than it is in > openocd.git cloned from gerrit with Tomek's stack of commits? That > doesn't make sense to me. > > >> I think merging the stuff in this alpha-experimental stage is a >> good thing > Then please do that in a branch that you take care of. > > Spencer clearly has reservations about merging the commits, > Tomek refuses to even rebase them, and while I haven't looked > at them yet I guess that I would find things that need more work. > > In my opinion, already depending on ft2232 is a hard blocker. > > >> After these two things one could try to use this for some experimental >> debugging, so it will be a working solution - just not polished (yet) (; > I can't understand why it would make any sense to include something > in openocd.git which is not finished? What is the point? We want to > make openocd.git better. We do it by only including finished changes. > The key to progress is to have *one small change* in every commit, > and many of them. It's really easy, but it requires outputting super > clean commits. Look at Linux. It works amazingly well there. It works for Linux since it is mature with a lot of devlopers and TESTERS. Not sure it is possible when critical and larges changes must be done. > If anyone needs help with git in order to work efficiently on OpenOCD > then there are several resources available, including this list and > even realtime chat help on irc.freenode.net #git. > > > //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/learnmore_122712 > _______________________________________________ > OpenOCD-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/openocd-devel Laurent http://www.amontec.com ------------------------------------------------------------------------------ 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/learnmore_122712 _______________________________________________ OpenOCD-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openocd-devel
