Am 04.02.2013 um 14:11 schrieb EBo: > On Feb 4 2013 4:18 AM, Michael Haberler wrote: >> Am 04.02.2013 um 11:29 schrieb EBo: > >>> In the past, and >>> I can read it between the lines now, that the invasiveness of the >>> modifications will take so much time and effort that lots of other >>> things gets pushed back. >> >> I dont agree on 'invasiveness'. In fact the RTAPI api is used >> basically unchanged, barring some new functions for PCI handling; the >> codebase is much cleaner and easier to maintain I would think. I am >> not aware of any outstanding bugs, in particular not the RTAI RTAPI. > > ok. How difficult would it be to break all the new stuff out into > modules, and build a modular framework for it?
well in fact that's what John is doing for RTAPI, with the intent to arrive at a universal build that supports RTAI, Xenomai, RT_PREEMPT and sim 'automagically'; that's not part of the current merge candidate-in-the-waiting though the design and flow stands, and I think it's another incremental change - basically linking RTAPI though support libraries for RT OS x,y or z, that is replaced by loading a .so module - the same stunt Jeff does with the interpreter; since Jeff's change wasnt noticed widely, we hope this one doesnt either. And every HAL module uses a similar method, so that's all safe ground. the idea is that eventually there is a single build per platform, regardless of the underlying RT OS; start it, code autodetects environment, does the right thing for the RT OS in question > >> Altogether I think that is a actually an incremental change. > > I would love to be proven wrong on this one, but I can see modularizing > monolithic code causing all sorts of unforeseen consequences. You might > be lucky though. or, of course, insanely bright ;) > >> I agree on 'lot of effort' but we're spending a disproportionate >> amount of time on kernel packaging, testing, configuration & build; >> skunkworks nows;) The RTAPI work has settled for quite a while. Btw >> some of that kernel packaging effort is driven by the 'everything on >> one CPU' limitation - without that it'd be easier sailing. > > what else do you see as changing if you break the 'everything on >> one CPU' limitation? the above was remark really was only about the new RTOS stuff, so I wouldnt know what to say here >>> I guess my 2C would be that it would make more >>> sense to incorporate these level of changes into v3 and back port >>> once >>> it is working and time allows. >> >> I dont think that will happen because I dont see anybody to do it, >> and I dont quite see the point either - I've on purpose left the >> option open to merge the new RT OS work into either master or >> v2.5_branch. That option is still open and undecided. > > So my question to you is how long do you keep the 2.5 branch if/when a > 3.0 branch becomes stable and fully functional? It should not be 0, but > it also should not be forever. I dont know. I would think the 2.5 branch is a maintenance-only thing, but the things that are added to it arent consistent with that. I cannot discern any communicated policies. Clearly there are lots of un-communicated policies around. Re length: look at it this way: the remapping code added to the interpreter was way more massive than the new RTAPI layer in terms of LOC. AFAICT there are no open bugtracker entries with bona-fide bugs (modulo Xmas wishes) wrt remapping, and none which were open more that a few weeks at most. That branch is entirely usable, and is used; the windows of outright brokenness were very short. > >> I dont care one way or the other, but one should be aware of the fact >> that merging this into master will accelerate deprecation of the >> v2.5_branch as few will see benefit in backpatching things into older >> branches, including me. Putting it further off will widen the gap >> even >> further. > > absolutely. But where do you dry the line between changes that are big > enough that they deserve to be slated for 2.6, 2.7, or 3.0? Working > incrementally is all find and good, and if we really refactor various > pieces of the code to make them more modular or update HAL so we can > drop NML, Each of these changes are serious enough to be designated a > revision to version bump. the line I see goes like so: The messaging-capable HAL layer will have a new API, which subsumes some of the existing HAL lib functionality. This should be a published, usable API, meant as a base the using code in the rest of Linuxcnc (task, GUI's) can be adapted for. I think it should also aim making HAL/RTAPI and the HAL-based GUI tools usable standalone, without the rest of Linuxcnc code draped around it; this isnt only a good sanitary exercise but I think is is a tempting tool for entirely new, not classic LinuxCNC-type applications. In fact I see no competing attempt for doing that, but I see lots of fellows fiddling Arduinos hoping to do something which that could do, and then some. This can be done while the existing code is linked to it traditional-style; there is no reason to remove this interface; only when everything is migrated the line should be cut. I dont see it as impacting existing functionality at all, so there's no reason to fork. That development can run in parallel with an existing branch, say off master, as a larger feature branch. > >>> The problem becomes you are spending a >>> LOT more time trying to shoehorn stuff into a structure that it does >>> not >>> well fit. Starting from a cleaner abstraction and moving forward in >>> a >>> methodological fashion will end up getting this done a lot faster >>> than >>> fighting the shoehorning. Also, if people have not done it already, >>> I >>> *strongly* recommend setting up a fully automated unit and >>> regression >>> test suite. I prefer the eXtreme Programming (XP) methodology >>> myself, >>> but any modern software engineering approach will benefit the >>> project. >> >> switching theme to other structural work, for instance removing the >> 'everything on one CPU' limitation: >> >> I dont quite believe in the big-bang architectural changes in the >> linuxcnc context. There are way too many moving parts affected in >> parallel, and that isnt doable by a single person either - and that >> is >> the modus operandi by and large of this project, give and take some >> exceptions. Barring a significant sudden cultural change, it is hard >> to see the team to do that. So I think de-facto forking the codebase >> is unrealistic. > > But there appear to be issues that are deeply ingrained enough that you > will likely never address them until someone either forks EMC or at > least makes a branch and changes things whole cloth. yes, but how you go about it? Let's take the old 'tool table' issue for example. I'm curious to see Seb's improvements. That said, I think it is very hard to do any substantial improvements in the existing codebase, for several reasons: 1. the NML limitations - size, and no communication patterns like RPC supported at a higher level; there's a legacy of failed attempts to do just that 2. the fact that the interpreter happily directly fumbles in global datastructures without going through getter/setter methods, which would be key to modular containment 3. the component architecture - realistically iocontrol functionality can be replaced by rather few and more generic code in task, making things way more flexible. 4. the storage/data model layer; that is really the easiest problem relative to the above, unfortunately it sees the most attention. So if you take that laundry list: as long as you dont take out NML, there isnt that much of a gain to be had. Then 2) needs fixing, thats semi-done for parameters, not for tool data. 3) has a proof of concept, and 4) has a candidate solution but waits integration the previous three. That's really my summary: without removing the large structural issues in the supporting layers, there isnt substantial progress to be had on the using layers. >> I would rather see it in a parallel evolution of replacement parts. >> For instance, the duplicate middleware (NML+HAL, both not quite >> fitting the bill) is a pressing structural problem. The way I would >> see forward is to make HAL messaging capable such that it can take >> over the - fairly minimal - messaging aspects of NML, and then start >> migrating components piecemeal. That would be a limited-impact >> approach as it can be done and verified in isolated contexts, and it >> would take the IMO most pressing issue off the list. > > Agreed. I would also advocate using that upgrade to implement/test > full regression/unit testing. well, I think just using one of the existing testing frameworks would help a lot here. > >> there are some issues which cannot be resolved by any amount of >> redesign, because they require a community decision or manpower. For >> instance, decide to deprecate Tcl use and eventually remove using >> code; or alternatively find a person which carries that effort >> forward >> onto a new base; I dont see either one. > > That is an issue, but how much code is effected with removing tcl? Axis is heavily affected by relying on Tkinter and Tcl code. Some of the lesser-used GUI's too. My guess is it's either Jeff raises the axe, or Gscreen becomes a viable replacement - whatever comes first. > IIRC, Ray's interface uses tcl, but is there more? > >> The big issue keeping *me* back here is actually relicensing. It is >> completely unrealistic IMO to address the above problem within the >> current GPL2only restriction. > > Is there a list of effected code that cannot be made (L)GPL2+? No, that's another blob of boring structural work, plus one of the decisions which dont come easy around here. I will push stronger for that once the current RTOS dust settles, and I do hope for active support. -m ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
