On 10/16/2012 7:00 PM, Michael Haberler wrote: > Seb, > > > Am 16.10.2012 um 23:14 schrieb Sebastian Kuzminsky: > >> On 10/16/12 13:48 , Michael Haberler wrote: >>> while several folks have been working on new realtime OS foundations, it >>> has become clear that the current configure support is inadaequate. >>> >>> I wrote up a proposal how to resolve this, and ask for comments. >>> >>> http://wiki.linuxcnc.org/cgi-bin/wiki.pl?RealtimeConfiguratonProposal >> Looks good, except I don't understand the part about user-space >> drivers. A lot of hardware drivers rely on kernel interfaces for >> discovering and communicating with the hardware.
I'm glad to see this discussion. The problem came home to me already with x86 architectures when I began following the CONFIG_PREEMPT_RT patch activity. Just for grins, let's not forget ./debian/configure, either. > <...> > It has no direct bearing on LinuxCNC, but there is a strong requirement for > such setups from a very different IT application area - high-frequency stock > trading, where it becomes common to shave off a microsecond or so by talking > directly to the hardware and bypass the OS. You might find some of these > weirdos over at the zeroMQ mailing list ;) [Full disclosure: I always get nervous when applications so far afield from CNC get mentioned. It's ok to be informed by them but let's try to avoid designing for some application we don't understand. - just my 2 cents worth.] >> I would think that build-time configurations that don't include kernel >> modules of some sort don't get these drivers, just like our current sim >> config doesn't get those drivers. Is that how you see it too Michael? > Whether a driver can be built or not depends on other parameters, like > architecture and platform; kernel vs usermode is just one part of the > equation here, but it is one. And one which we will ultimately have to work out, just as we are this one, so that future implementers/users have an easier time building systems. For the time being, I think it's just something to keep in mind. >> I'm also a bit concerned that there are so many configs now - 6 are >> listed on the wiki page of your proposal. It implies a lot of coding, >> building, and testing. It also implies a much more complicated install: >> which of the 6 Live CDs should a user try first? > No, it does not, because it does not follow - a parameter combination which > can be configured does not necessarily make it a sensible build target for > binary distribution. > > For instance, building a binary package for "ARM" where you dont even know in > advance what type of peripheral the user's board has is nonsense - in this > space you dont have the platform monoculture of Intel-based PC platforms. > Once you have the drivers then it makes sense building a binary, but that > wont be us in most cases. > > However, this scheme enables you to build the *hardware-independent* part of > LinuxCNC such that it is an option to run *at all* - note we are just > maneuvering out of the single-operating system, single architecture lock-in. This is my personal desideratum---to see the configuration process factored as cleanly as possible. It doesn't disturb me that we may introduce a classification system which allows for combinations we don't find useful (at least not yet) so long as it allows for easy management of the combinations we do use. Anyone who has worked in artificial intelligence, mathematical logic, or linguistics understands the problem that any system sufficiently powerful to be useful also allows one to construct ambiguous or nonsensical statements. Nevertheless, we can't get around the fact that a lot of testing remains to be done at every step. As for LiveCDs, I think that concept is viable only for pretty traditional x86 PCs and having more than one is no more obnoxious than having a plethora of Linux distributions or even of flavors of specific Linux distributions. The website and the wiki remain the places to provide guidance on selection. >> I assume exactly two of those configs will turn out to be the most >> useful: one for running real machines and another for casual testing on >> 'normal' computers, like our current 'realtime' and 'sim' builds. Maybe >> it'd be best to identify which configs are the most useful, and then >> focus our effort on those configs/platforms? > Which architecture? PC: likely so. > > Concentrating efforts is a good idea, and to make an educated decision we > need to find out what is the best combination. This why I mentioned 'explore > kthreads with rt-preempt' and both user and kernel mode with xenomai. I dont > think all these options will survive in actual usage, and I dont think it > would be desirable from a support perspective, but you cannot even *explore* > them now without patching up the build system massively - with a high chance > that these patches dont find their way back in in a useful shape. > > And that decision includes semi-technical aspects, like 'how long will X be a > viable platform', so it might change over time. > > This is why I'm pushing the issue to the current LinuxCNC version - the RTAI > foundation becoming non-viable has a very distinct chance of happening within > the remaining lifespan of LinuxCNC2 (which could be very long). There's no reason a priori to assume Xenomai will be viable forever either. Again, this is a basic reason for building as much flexibility as we know how to into the process from the ground up. I know I'm preaching to the choir, but the biggest problem with RTAI isn't that development may stop but that users keep demanding to use the latest and greatest Linux kernel, almost always for reasons that have nothing to do with CNC. I have no problem at some point having to tell users that if they want to use RTAI for whatever reason they'll have to use the last available kernel+patches and possibly only on a subset of available x86 machines. This will become increasingly untenable as the arrow of time moves forward but it's the best we can do unless we are willing to undertake RTAI development ourselves. > --- > > I believe we should think about the future of LinuxCNC under the assumption > of a potentially distributed setup - an 'RT outboard', 'CNC controller', > whatever, and some other machine running UI and other command & control > components. All of the above is only applicable to the former; the latter > could run on just about anything, maybe even machines nobody thinks about > using for such a task because it was plain impossible so far. Maybe in two > years folks glue an old iPad to their lathe, who knows. > > Thinking in terms of such a setup is an architectural point of view and does > not imply one has to provide binary blobs for any conceivable combination. Seems to me this brave new future has been our present for some time but it's been hobbled by our current software architecture. > This is why I think going forward we should separate out > HAL+RTAPI+comp+modules into a separate project; the rest of LinuxCNC would > just use this part, which is the only part subject to above considerations. And now we return full circle to some of your earliest proposals :-) I admit I get twitchy when I read "separate" project but but I can live with a parallel project within the LinuxCNC framework. Otherwise, the proposed division conjures up issues like we already face with the RTAI and Xenomai projects. > - Michael > > >> -- >> Sebastian Kuzminsky >> >> Where is everybody else? Regards, Kent PS - sorry for quoting most all of the previous message but it was hard to see where I could pare it down. ------------------------------------------------------------------------------ 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_sfd2d_oct _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
