add test for mb2hal version 1.0

[hansu]

This adds a test for mb2hal consisting of two parts:

• compare the debug output of mb2hal
• compare the created pins including type

I didn't manage to cover this in one test case (or in one instance), because the output of the second part (show pin ...) overlaps the debug output of mb2hal. I have no really idea how to wait until mb2hal's initializing printouts are ready.
Maybe someone has a better idea.

[petterreinholdtsen]

If I read the build failure correct, the test in #2274 is broken with 2.8 too? Perhaps the fix in #2270 is needed in 2.8 too?

[hansu]

No, this works locally on 2.8. Seemed to be something with the buildbot. Now after a force push it passes.

[petterreinholdtsen]

[Hans Unzner]

No, this works locally on 2.8. Seemed to be something with the buildbot. Now after a force push it passes.

How strange. Anyway, the test seem to be working now and look good to me.

…

-- Happy hacking Petter Reinholdtsen

[SebKuzminsky]

The build failure is back, it seems to be something intermittent:

• http://buildbot.linuxcnc.org/buildbot/builders/1301.rip-precise-rtai-i386/builds/9069/steps/runtests/logs/stdio
• http://buildbot.linuxcnc.org/buildbot/builders/1401.rip-wheezy-rtai-i386/builds/7682/steps/runtests/logs/stdio

I've only ever seen it fail on RTAI, never on Preempt-RT. Might be an artifact of the small sample size...

It fails 100% of the time for me in a local VM running Wheezy with our RTAI kernel.

It looks like the test failure is due to maybe a race condition in what component id is assigned to the mb2hal component - sometimes it's 4 and sometimes it's 5.

[hansu]

Then it seems that I can't use the simple "compare with expected result" method.
Either I use some more complex diff method with external tools or maybe it's sufficient to compare only the created pins?

[SebKuzminsky]

After looking at this closer, I don't think it ever worked on RTAI, and our 2.8 build has been broken since this went in, in January.

For some reason I don't yet know, uspace and RTAI run different things at startup, so later component IDs are different. You can see this by running halrun -V on both platforms:

Uspace

uspace$ halrun -V
HAL: initializing hal_lib
HAL: initializing component 'halcmd129436'
smalloc_dn: shmem available 1048184
HAL: component 'halcmd129436' initialized, ID = 02
halcmd: 

RTAI

rtai$ halrun -V
.
HAL: initializing hal_lib
RTAPI: initing module HAL_LIB_991
RTAPI: module 'HAL_LIB_991' inited, ID = 02
HAL: initializing component 'halcmd991'
RTAPI: initing module HAL_halcmd991
RTAPI: module 'HAL_halcmd991' inited, ID = 03
smalloc_dn: shmem available 347868
HAL: component 'halcmd991' initialized, ID = 03
halcmd: 

Note that uspace starts just one component (halcmd), while RTAI starts two components (HAL_LIB and halcmd).

HAL assigns components unique ids at load-time, and the ids are just sequential integers (kind of like pids of regular unix processes). So all components loaded after this will also have different ids on these two platforms.

I don't want to get into why RTAI needs the HAL_LIB component, i think the better fix would be to change the test so it doesn't rely on the component ID being a particular number.

[hansu]

This makes the test way more tolerant: #2455