[BRLTTY] Are changes needed for systemd 247.1?

[Alexander Epaneshnikov]

09.12.2020 01:17, Dave Mielke пишет:
> [quoted lines by Alexander Epaneshnikov on 2020/12/09 at 01:05 +0300]
>
>> you need to change:
>> ACTION=="add", GOTO="brltty_systemd_add"
>> to:
>> ACTION!="remove", GOTO="brltty_systemd_add"
>> without it brltty stops on systemd reload
> I'd prefer to stay with == as != let's unexpected things happen. Do you know
> what the unexpected action is? Is it change? Does duplicating the add line and
> changing add to change fix it? Other actions to try would be bind and unbind.
>
that was recommendation from upstream systemd.
snip from systemd news:
>            • All rule files that currently use a header guard similar to
>              ACTION!="add|change",GOTO="xyz_end" should be updated to use
>              ACTION=="remove",GOTO="xyz_end" instead, so that the
>              properties/tags they add are also applied whenever "bind" (or
>              "unbind") is seen. (This is most important for all physical device
>              types — those for which "bind" and "unbind" are currently
>              generated, for all other device types this change is still
>              recommended but not as important — but certainly prepares for
>              future kernel uevent type additions).
>
>            • Similarly, all code monitoring devices that contains an 'if' branch
>              discerning the "add" + "change" uevent actions from all other
>              uevents actions (i.e. considering devices only relevant after "add"
>              or "change", and irrelevant on all other events) should be reworked
>              to instead negatively check for "remove" only (i.e. considering
>              devices relevant after all event types, except for "remove", which
>              invalidates the device). Note that this also means that devices
>              should be considered relevant on "unbind", even though conceptually
>              this — in some form — invalidates the device. Since the precise
>              effect of "unbind" is not generically defined, devices should be
>              considered relevant even after "unbind", however I/O errors
>              accessing the device should then be handled gracefully.
so i think !=remove would be indeed correct.

-- 
Sincerely, Alexander.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://brltty.app/pipermail/brltty/attachments/20201209/4d6d0150/attachment.html>