I've just pushed a new update to the unofficial patchset; it is now at
version 20170727 and is based on the latest upstream default (f5ffd187 at
this moment). (A little later than originally planned, but at least it's
not Valve Time.)
https://sourceforge.net/u/uecasm/etherlab-patches/ci/default/tree/#readme
Feedback is welcomed.
Notable changes:
- I've left the "ethercat diag" command patches in for now but note that
upstream has added a new command "ethercat crc" that does basically the same
thing. I'll probably drop "diag" in a future patchset but until then people
can try them both out and see which one you prefer or if anything from
"diag" should be patched into "crc".
- Patches have been reorganised into directories and locally renumbered;
you can check the history of the readme or of the patches themselves to
follow their history (in some cases you might need to add the -f flag to
tell hg to follow the history through renames). This does mean that the
patches are not fully alphabetic ordered anymore; intended application order
is in the series file as usual, and complete instructions are in the readme.
I'm open to suggestions for further reorganisation, especially of the "base"
patches.
- I've also added a script and some notes for people who prefer applying
patches directly in Git mostly without passing through Mercurial along the
way. (The preferred option is still to apply the patches in Mercurial first
though.) The script is a little dumb and can handle comments and removing
lines from the series file (if you want to exclude some patches) but not
guards.
- There are no longer any API "breaking change" patches (ie. existing
app code based on master 1.5 should still compile with all patches applied;
although sadly this does mean that there's a reverse breakage and code that
compiled with the previous full patchset might need to be modified slightly
for this one).
- However there are still ABI-breaking changes scattered over several
patches (in general, anything that changes ecrt.h or ioctl.h). Typically
this just means that you need to recompile both the kernel and userspace
components (for both Etherlab and your application). I've added some
example code in the readme showing how to detect incompatibility between app
and library, which is recommended to add to your application startup if not
already done.
- Folded former patch 0032 into
base/0021-Clear-slave-mailboxes-after-a-re-scan.
- Folded former patch 0033 into
base/0023-Sdo-directory-now-only-fetched-on-request.
- Folded former patch 0037 into
base/0016-If-enable-rtmutex-use-rtmutexes-instead-of-semaphore.patch.
- Patch base/0017-Master-locks-to-avoid-corrupted-datagram-queue
(formerly patch 0011) has been made no-op when compiled for RTDM to avoid
introducing Linux locks (and possible secondary mode and/or deadlocks).
Along with the change to base/0016 discussed below, I *think* this should
make the patchset completely RTAI/Xenomai-safe, although it's possible patch
base/0018 might need similar treatment. (Let me know!)
- Patch base/0009-Avoid-changing-running-slaves-DC-offset (formerly
patch 0029) has been tweaked slightly to avoid resetting the drift filter
for slaves in SAFEOP or OP even if it updated their transmission delay. I
don't actually have any evidence of this being a problem either way but I
suspect this will produce slightly smoother clock transitions for active
slaves.
>From http://lists.etherlab.org/pipermail/etherlab-dev/2016/000572.html (Knud
Baastrup):
- Patch 0061 was not actually applied but it made me realise the
original problem with patch base/0016 (formerly patch 0004), so I have
dropped former patch 0007 and reworked former patch 0004 slightly. The
patch should now be cleaner against upstream sources and should be safe for
RTAI use as well now. (Alternatively, you can think of it as folding patch
0007 and patch 0061 into 0004 and then moving one lock instance out to the
calling method where it had originally been to make it RTAI safe.) Note
that I have still not actually tested this against RTAI but since there are
now no new locks it should be ok.
- Patch 0062 has been folded into patch
base/0019-Support-for-multiple-mailbox-protocols (formerly patch 0005).
- Patch 0063 has been folded into patch
base/0017-Master-locks-to-avoid-corrupted-datagram-queue (formerly patch
0013).
- Patch 0064 has been folded into (and thus replaced) patch
features/complete/0002-add-sdo-write-with-size (formerly patch 0038).
While I still personally prefer the single-API version, this makes it
a non-ECRT-API-breaking change, although still an ABI-breaking change.
- Patch 0065 has been folded into (and thus replaced) patch
features/complete/0003-sdo-requests-complete (formerly patch 0039).
Although I excluded ecrt_slave_config_alloc_sdo_request because it's
not really any different from the other two create methods. (You can always
pass 0 for the index/subindex if you want that.)
While I still personally prefer the single-API version, this makes it
a non-ECRT-API-breaking change, although still an ABI-breaking change.
- Patch 0066 has been rejected. I don't think it's worthwhile adding an
entirely separate API for this; just verify that your app was compiled
against the correct version. I've added some notes in the readme about doing
that, and added a patch (base/0000) to make it easier to distinguish patched
and unpatched sources and binaries. (And there are plenty of other patches
that break ABI; it doesn't seem useful singling this one out.)
>From http://lists.etherlab.org/pipermail/etherlab-users/2016/003112.html
(Dr.-Ing. Wilhelm Hagemeister):
- I have not applied this patch, since it limits performance, it's a bit
device-specific, and it came from IgH themselves.
>From http://lists.etherlab.org/pipermail/etherlab-dev/2017/000573.html
(Patrick Brünn):
- Imported as base/0005-support-vm_fault-kernel-v4.10.
>From http://lists.etherlab.org/pipermail/etherlab-dev/2017/000581.html
(Gavin Lambert):
- The changes suggested in this post (and the later correction) have
been folded into base/0019-Support-for-multiple-mailbox-protocols (formerly
patch 0005).
>From http://lists.etherlab.org/pipermail/etherlab-dev/2017/000583.html
(Graeme Foot):
- Imported as devices/0005-cx2100-2.6, although it only supports Linux
2.6.32.
- Theoretically forward-ported to Linux 4.9 as devices/0006-cx2100-4.9
-- it compiles, at least; I don't have the hardware to test it.
- I assume that this is intended only for 32-bit systems, as there is
some code that generates suspicious warnings when compiled for 64-bit. I
haven't tried to correct this.
>From http://lists.etherlab.org/pipermail/etherlab-dev/2017/000587.html (Nir
Geller):
- I'm not sure what to do about this patch. AFAIK in theory the change
shouldn't be needed (there's a separate EoE thread which should be running
in Linux kernel mode, so app code shouldn't need to do anything in
particular other than getting lock callbacks correct if not in vanilla
usermode) but as I don't use EoE myself I don't know enough about it to say
for sure. Any chance someone else can chime in on this one?
>From http://lists.etherlab.org/pipermail/etherlab-dev/2017/000592.html
(Steffen Dirkwinkel):
- I haven't applied the suggested patch, but since ssize_t is only used
in one place, and it really didn't need to be (especially since no existing
callers appear to use the return value anyway), I've opted to remove this
usage instead, as patch base/0006-avoid-ssize_t.
>From http://lists.etherlab.org/pipermail/etherlab-dev/2017/000595.html
(Graeme Foot):
- Imported patch 0001 as
base/0007-replace-fprintf-calls-with-EC_PRINT_ERR.
- Imported patch 0008 as
base/0008-read-reference-slave-clock-64bit-time. (Perhaps this should have
been a feature patch instead, but it seems harmless enough.)
- Imported patch 0010 as
features/rt-slave/0001-allow-app-to-process-slave-requests-from-realtime.
>From http://lists.etherlab.org/pipermail/etherlab-dev/2017/000596.html
(Ricardo Ribalda Delgado):
- This patch is already included in the default branch.
>From http://lists.etherlab.org/pipermail/etherlab-dev/2017/000600.html
(Gavin Lambert):
- I have elected to not make the change mentioned here, as my analysis
wasn't quite correct and it shouldn't make any practical difference. And
the change would introduce busy cycles, which is undesirable.
Let me know if I've missed any patches, or if you think some of them were
mishandled.
_______________________________________________
etherlab-dev mailing list
etherlab-dev@etherlab.org
http://lists.etherlab.org/mailman/listinfo/etherlab-dev
