-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/16/2012 6:26 PM, Michael Haberler wrote: <snip> > ----> The major limitation of all userland thread styles is PCI > driver support. > > That is not a showstopper for a code merge, but it is on the > critical path for all of the userland styles to become a viable > base for working with non-parport/gpio hardware, and the issue is > isolated in scope but needs determined attention by someone in the > know (which I am not, and hope I do not to have to become one). See > work items below.
<snip> > PCI support for userland thread styles. > --------------------------------------- we *urgently* need a shim > layer to map the kernel PCI environment such that existing drivers > can be made to work without extensive rewrite. > > The goal of this work item is roughly this: > > - survey the existing drivers for PCI support needs - evaluate the > existing RTAPI PCI code (see src/rtapi/rtapi_pci.*) - evaluate > upci.c/h and outside sources like libpci or libpciaccess if that > is some help, and integrate if it does - develop a shim (include > file and maybe some support routines) to get away with a > conditional include and maybe a library - make sure the result > works and develop testcases for common hardware if possible - note > changes were made to hal_vti and hal_motenc to use rtapi_pci but I > am fairly sure this is untested and broken. > > I think this is possible, attainable in finite time, and I would > be very grateful if somebody else could pick that up and deliver. I have been looking into this somewhat, and while I am intimately familiar with PCI and PCI Express, I am less aware of the state of software support on the Linux side. That said, it appears that RTAI and xenomai-kernel can use kernel level support for PCI and carry on mostly as usual. With user-mode threads, (preempt-rt or xenomai-user), something at the kernel level needs to be invoked to handle the memory space remapping. The rtapi_pci code is using the uio_pci_generic driver, which seems like a reasonable choice (to my limited view, anyway), however I concur that it currently seems to be broken. I am not yet sure exactly *HOW* broken it is, but will report if I get anything working...right now I'm unable to bind to a device using rtapi_pci, although I *can* bind devices manually at the command line. The LinuxCNC driver suite does benefit from the fact that it appears pretty much nothing is doing interrupts, and DMA (scatter-gather or contiguous) is non-existent. That limits the amount of support required from any software 'shim' layer to the bare essence of mapping a PCI BAR into user-land memory space. If anyone has a strong preference for a PCI support scheme that can work across the various options, please comment. I am no Linux kernel guru, and am likely unaware of several different possible options for driver writing. At the moment, it appears to me that the uio_pci_generic driver should be suitable for use by most/all LinuxCNC drivers when not running in kernel space. If this turns out to not work well with xenomai-user, it should be reasonably straight-forward to implement similar functionality as a xenomai rtdm driver. <fingers crossed> - -- Charles Steinkuehler [email protected] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlCm4SoACgkQLywbqEHdNFx/nwCgiWSi8/f2+lt6dHqZdnc7f6kC cXQAoPjyfl53JN4iCR0kbUnidpCIwzb8 =v/bM -----END PGP SIGNATURE----- ------------------------------------------------------------------------------ Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
