Am 04.02.2013 um 11:29 schrieb EBo: > On Feb 4 2013 2:58 AM, Michael Haberler wrote: >> Am 04.02.2013 um 10:25 schrieb EBo: >> >>> LinuxCNC-3.0 then as a design philosophy? >> >> I would rather call it sheer necessity in some cases, although >> individual perceptions of urgency obviously differ. >> >> For instance, I dont think broadening the base of RT operating >> systems, or removing the 'everything on one CPU' limitation requires >> a >> lot of philosophical thinking; it is rather 'what is the minimum to >> be >> done asap from preventing this project from keeling over'. That is >> why >> I postponed from working on LinuxCNC3 grand visions until the RT OS >> stuff is done. >> >> Of course there's always an alternative, the bits dont go away - keep >> scavenging hardware which somehow, in some way fits the current >> operations model. That is a dwindling option afaict, nevermind some >> of >> the more bizarre limitations attached. > > Well, I can see this going two ways. EMC works now.
well, the new RTOS branches do, too - sticking with that for the moment: > 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. Altogether I think that is a actually an incremental change. 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. > 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. 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. > 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. 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. 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. 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. re motion: I think piecemeal is entirely possible here too - branch off a second component, build in parallel, modularize, and leave it as an option. When it becomes clear it's beneficial, folks will switch; if not, then not - no damage done except some lines of halcmd. I think that doing such structural changes without rocking the boat too much is one of the large - and I find very interesting - challenges, a bit like nailing a pudding onto the wall ;) -Michael > > Anyway, that's my 2C > > EBo -- > > > ------------------------------------------------------------------------------ > 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 ------------------------------------------------------------------------------ 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
