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.

_______________________________________________
This message was sent via the BRLTTY mailing list.
To post a message, send an e-mail to: BRLTTY@brltty.app
For general information, go to: http://brltty.app/mailman/listinfo/brltty

Reply via email to