All of lore.kernel.org
 help / color / mirror / Atom feed
From: Max Staudt <max@enpas.org>
To: Vincent Mailhol <vincent.mailhol@gmail.com>,
	Marc Kleine-Budde <mkl@pengutronix.de>
Cc: Wolfgang Grandegger <wg@grandegger.com>,
	linux-can@vger.kernel.org, Oliver Neukum <oneukum@suse.com>,
	linux-kernel@vger.kernel.org,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Jiri Slaby <jslaby@suse.com>
Subject: Re: [PATCH v3] can, tty: elmcan CAN/ldisc driver for ELM327 based OBD-II adapters
Date: Sat, 12 Mar 2022 22:21:42 +0100	[thread overview]
Message-ID: <20220312222142.21591629.max@enpas.org> (raw)
In-Reply-To: <CAMZ6RqJJ-PO=WeFeuXk4iC9GHLXz_ZMWtsVCm6sGVGbmeE5U1Q@mail.gmail.com>

Hi Vincent,
(Hi Marc,)

Thank you for your in-depth look at it - especially regarding stale
things that reflect its age, such as cf->can_dlc vs. cf->len. This
driver has been gathering some dust. I've reworked the code according
to your review.



@Marc - could you please have a look at this?

The elmcan code currently has a dummy mailbox_read() function for
rx_offload because can_rx_offload_add_fifo() requires it - is this
intentional?




@Vincent - two more things have remained, and I hope it's okay once I
explain them:

1. _memstrcmp() - memcmp() vs. str(n)cmp()

The _memstrcmp() function does not compare strings, it compares raw
buffers. I am just using C strings for the fixed buffers to compare
against, as that allows for shorter and easier to read code. The NUL
byte at the end of those strings goes unused.

Also, I have not looked at the assembly produced, since the semantics
are different: str(n)cmp() needs to look for NUL bytes in the buffer(s),
which is unnecessary here. As a bonus, NUL will never even occur
because my code filters those bytes out upon reception from the UART
(it's a documented quirk of the ELM327).

Finally, even if I were to use strcmp(), the code would still look just
as ugly. Except the machine would also look for NUL bytes, and the next
human to read the code would wonder why I'm comparing strings and not
buffers.

Hence memcmp(), to help the code self-document and the compiler
optimise - I hope that's okay.



2. Useless parentheses in a for loop's condition:

I left those in there because it gets hard to read otherwise, IMHO.
It's really a matter of taste though, and if you insist, I'll remove
them. With if, it's easier to keep it readable:

	if (a == 1
         && b == 2) {
		...
	}

Whereas with for, I've already used multiple lines to visually separate
the initialiser, the condition, and the incrementer. Hence the
parentheses to visually separate the two subconditions.

Matter of taste really, and I'll change it if you insist.




That's it!
Everything else is already patched for a future v4 of the code. I'll CC
you once I send that out. But I'd like to wait for Marc's feedback
first.



Thanks,

Max

  reply	other threads:[~2022-03-12 21:21 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-07 21:43 [PATCH v3] can, tty: elmcan CAN/ldisc driver for ELM327 based OBD-II adapters Max Staudt
2022-03-07 21:57 ` Greg Kroah-Hartman
2022-03-07 22:00   ` Max Staudt
2022-03-08  7:01 ` Vincent Mailhol
2022-03-09 12:54   ` Max Staudt
2022-03-09 13:49     ` Vincent Mailhol
2022-03-12 21:21       ` Max Staudt [this message]
2022-03-15 10:21         ` Marc Kleine-Budde
2022-03-17 21:05           ` Max Staudt
2022-03-14 22:04       ` Marc Kleine-Budde
2022-03-17 20:23         ` Max Staudt
2022-03-17 20:57           ` Marc Kleine-Budde
2022-03-17 21:08             ` Max Staudt
2022-03-14 22:00   ` Marc Kleine-Budde
2022-03-14 21:58 ` Marc Kleine-Budde
2022-03-17 20:18   ` Max Staudt
2022-03-17 20:55     ` Marc Kleine-Budde
2022-03-21  2:06       ` Max Staudt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220312222142.21591629.max@enpas.org \
    --to=max@enpas.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=jslaby@suse.com \
    --cc=linux-can@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mkl@pengutronix.de \
    --cc=oneukum@suse.com \
    --cc=vincent.mailhol@gmail.com \
    --cc=wg@grandegger.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.