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. On a PC with say PCI cards that is surely the case. View beyond that - assume a usermode RT setup on say an ARM architecture with memory-mapped I/O. There would be no point doing kernel roundtrip if you dont need it. Some I/O architectures are so trivial that it would be hard to figure what useful service a kernel could provide. btw 'Usermode driver' does not imply 'does not use kernel services' - have a look at http://www.bitmuster.org/projects/emc.html , or http://www.rtnet.org . 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 ;) > 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. > 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. > 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). --- 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. 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. - Michael > -- > Sebastian Kuzminsky > > > ------------------------------------------------------------------------------ > 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 ------------------------------------------------------------------------------ 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
