[etherlab-dev] ec_lock_* vs. ec_ioctl_lock in master/ioctl.c

[Gavin Lambert]

On 5 March 2018 22:58, quoth Esben Haabendal:
> The multiple process world can be different though.  You basically end up
> with a new EtherCAT API.  A combination of the etherlabmaster API and a
> custom named semaphore API.  Without this, applications will not work
> properly together.  Why not include such a feature directly in
> etherlabmaster?  Without it, I think we are making the user-space
> applications (non-RTDM) into a second-class citizen.

If you have multiple independent processes then they must (of necessity) either operate on separate masters (in which case no locking beyond what the kernel already does is required) or they must all communicate (through some mechanism of your own devising) with a single process who "owns" the master.  The master library does not allow you to reserve or activate a single master concurrently in separate processes.

If you have multiple tasks within a single process operating on the same master (eg. multiple cycles with different intervals) then they _should_ operate on different domains, and *must* coordinate their calls to the ECRT APIs in some fashion.  In upstream Etherlab, this requires application-level locking.  In the current patchset, the locking is done for you (except for RTDM), but I'm not entirely convinced this is the correct design choice (see my other reply).

If you have one process that is running a realtime application loop and another process that only performs non-realtime tasks (eg. injecting CoE requests), even on the same master, then all versions of Etherlab handle this for you without requiring additional locking.  This is how you can still use the "ethercat" command line tool while running a realtime application.