emc2 ver2.2.x released.
The emc2 team released ver2.2.0 on November 5th, followed by 2.2.1 a few days later.New "components" have been added along with a "new" driver for 8255 based PCI cards.
Additional claims include:
* x86_64 port
* powerpc port (sim only)
* For SMP configurations, yadda yadda...
v2.2.1 "fixes several important packaging problems". One thing that isn't mentioned is a check made for compilers earlier than gcc-3.0. If you have a 2.4.xx series kernel compiled with gcc-2.95.3, you're gonna have to recompile and/or upgrade to 2.6.xx. Unfortunate, as some smaller systems boot and run faster with 2.4.xx kernels. Yet a cursory look at the source code shows nothing that would cause gcc-2.95 to fail - What would throw errors are certain constructs specific to 2.6.xx series kernels.
Prediction: Support for 2.4.xx series kernels will be "dropped", yet little will be done to maximize the use of 2.6.xx features.
So far, 908 compile time warnings for i386 builds, 928 warnings for x86_64 (both 2.6.22-rtai kernels).. Forget PowerPC, that throws several fatal errors.. (Haven't even tried installing the python2.4 dependencies yet). One would have thought that with the use of autoconf, if Python.h was not found, the relevant sections of the build would be automatically disabled.. No, too easy.. Instead, configure throws an error and prompts you to use --disable-python.
* PCI based 8255 driver.
Umm... OK... Don't see any calls to the PCI subsystem to register the driver or any of the deprecated pci_find functions - It *may* work with 2.6.22 kernels, but I suspect it will go tits up with later kernels that have a far more aggresive power saving stratagy (anyone for 2.6.24 ?). I might be tempted to try it with an Amplicon PCI272 card when RTAI has some newer x86_64 patches.
* x86_64 port
If it wasn't for the dubious practice of cut'n'pasting assembly code from asm/bitops.h in to rtapi_bitops.h in an attempt to fix an "issue" someone was having with includes, it would have compiled for x86_64 a long while ago. The functions declared in rtapi_bitops.h are used for lightweight mutex to "protect" writes from user space - However, some of them are currently not thread safe, nor do they exclude the possibility of a realtime thread interrupting them. The solution is to disable/enable hardware interrupts, or better yet, use native RTAI locks.
* powerpc port
The same comments regarding bitops.h apply, and additionally, if get_cycles() had been used in place of rdtscll(), the only remaining compile time problem would have been sys/io.h & iopl() calls. Both, easily handled with appropriate autoconf tests and the use of autoheader. However, like 64bit support, endian issues would surely bite if this stuff were ever to run on a real PowerPC system rather than just (sim) mode.
Now that people have the opportunity to run on 64bit platforms (and SMP configurations), some interesting bugs are waiting to bite. First, a little snippet of code:
for (b = 0; b < 8; b++) {
/* get the data, add to output byte */
if ((*(slot->digout[b].data)) && (!slot->digout[b].invert)) {
outdata |= mask;
}
if ((!*(slot->digout[b].data)) && (slot->digout[b].invert)) {
outdata |= mask;
}
mask <<= 1;
}
Apart from being a little ugly, this loop suffers from a race condition - There are no locks protecting the slot struct, so if either (or both) data & invert change, the mask could be wrong. Assuming the two variables are boolean, a neater solution would be:
int b = 8;
while (b--) {
/* get the data, add to output byte */
outdata |= ((*(slot->digout[b].data)) ^ (slot->digout[b].invert))
outdata <<= 1;
}
Considerably shorter, avoiding multiple reads of the same variables, and will run faster. This snippet is from hal_ppmc.c in the write_PPMC_digouts() function - Being part of the realtime code, it should be a clean and fast as possible.
* v2.2.1 "fixes several important packaging problems".
Right.... All user space & kernel modules are rolled in to a single package, the core debian/ files are generated by a "configure" script with a whole bunch of bogus dependencies thrown in.. Dephelper and module-assistant exist in Debian/Ubuntu repositories specifically for the purpose of providing tools to build kernel/user-space packages. (better not say much about the bogus copyright claim in debian/rules Eppler: Just because you bastardised the file, you do not have a prior claim on copyright).
I wonder what other files have dubious copyright/licence claims.... For sure, it is not all (L)GPL code.
yapps2 is released under the MIT Open Source licence (FOSS compatable)
OpenGLTK.py is BSD
dialog.tcl is copyright of the Regent of the University of California & requires verbatim copy of the license.terms to accompany it (and any modified work).
togl.c also fals under similar terms and conditions...
Let's not forget large portions are public domain code (as released by NIST), and so are free of copyright... Changing a couple of lines or reformatting can hardly be the basis for bestowing (L)GPL status on a file.