[strace/strace] Add lirc ioctl decoding (PR #208)

[esyr]

On Mon, Feb 07, 2022 at 10:58:01AM -0800, Sean Young wrote:
> > There are also
> > LIRC_CAN_SEND_RAW, LIRC_CAN_SEND_MODE2, LIRC_CAN_SEND_SCANCODE,
> > LIRC_CAN_SEND_LIRCCODE, LIRC_CAN_REC_RAW, LIRC_CAN_REC_PULSE,
> > LIRC_CAN_REC_LIRCCODE, LIRC_CAN_SET_REC_FILTER, LIRC_CAN_GET_REC_RESOLUTION,
> > and LIRC_CAN_SET_REC_DUTY_CYCLE_RANGE flags seem to be missing.
> 
> I've added LIRC_CAN_REC_LIRCCODE, LIRC_CAN_SEND_LIRCCODE (may be used in
> pre-4.16 kernels) and LIRC_CAN_GET_REC_RESOLUTION was just missing.

> The other
> onces were never implemented, out-of-tree or not. They should have never
> been added to the header in the first place.

Generally it is worth adding such constants to the xlat file in
comments (with a reason why they were omitted), so those who are looking
at it afterwards won't spend too much time to figure out they are
missing (as it is not pointed out in the kernel header explicitly, only
in the documentation).

> > LIRC_GET_LENGTH commands doesn't seem to be checked.
> 
> Yes, this is true. LIRC_GET_LENGTH is not a thing anymore since kernel v4.16,
> however I've added a test.

strace is expected to be compatible with a range of kernel versions
(as old as 2.6.18, supposedly).


-- 
Reply to this email directly or view it on GitHub:
https://github.com/strace/strace/pull/208#issuecomment-1034487449
You are receiving this because you are subscribed to this thread.

Message ID: <strace/strace/pull/208/c1034487449 at github.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strace.io/pipermail/strace-devel/attachments/20220209/cdb4934b/attachment.htm>