From: "Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>
To: Jiri Slaby <jirislaby@kernel.org>, Johan Hovold <johan@kernel.org>
Cc: "Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
linux-serial <linux-serial@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
"Tobias Klauser" <tklauser@distanz.ch>,
"Richard Genoud" <richard.genoud@gmail.com>,
"Nicolas Ferre" <nicolas.ferre@microchip.com>,
"Alexandre Belloni" <alexandre.belloni@bootlin.com>,
"Claudiu Beznea" <claudiu.beznea@microchip.com>,
"Vladimir Zapolskiy" <vz@mleia.com>,
"Liviu Dudau" <liviu.dudau@arm.com>,
"Sudeep Holla" <sudeep.holla@arm.com>,
"Lorenzo Pieralisi" <lorenzo.pieralisi@arm.com>,
"Shawn Guo" <shawnguo@kernel.org>,
"Sascha Hauer" <s.hauer@pengutronix.de>,
"Pengutronix Kernel Team" <kernel@pengutronix.de>,
"Fabio Estevam" <festevam@gmail.com>,
"NXP Linux Team" <linux-imx@nxp.com>,
"Andreas Färber" <afaerber@suse.de>,
"Manivannan Sadhasivam" <mani@kernel.org>,
"Russell King" <linux@armlinux.org.uk>,
"Florian Fainelli" <f.fainelli@gmail.com>,
bcm-kernel-feedback-list@broadcom.com,
"Pali Rohár" <pali@kernel.org>,
"Kevin Cernekee" <cernekee@gmail.com>,
"Palmer Dabbelt" <palmer@dabbelt.com>,
"Paul Walmsley" <paul.walmsley@sifive.com>,
"Orson Zhai" <orsonzhai@gmail.com>,
"Baolin Wang" <baolin.wang7@gmail.com>,
"Chunyan Zhang" <zhang.lyra@gmail.com>,
"Patrice Chotard" <patrice.chotard@foss.st.com>,
linux-riscv@lists.infradead.org
Subject: Re: [PATCH v3 0/4] tty: TX helpers
Date: Wed, 7 Sep 2022 13:16:23 +0300 (EEST) [thread overview]
Message-ID: <4e9b4471-a6f2-4b16-d830-67d253ae4e6a@linux.intel.com> (raw)
In-Reply-To: <dec6d5c4-45b7-f087-95f4-bf1dae9e9d27@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 2755 bytes --]
On Wed, 7 Sep 2022, Jiri Slaby wrote:
> On 06. 09. 22, 13:30, Johan Hovold wrote:
> > On Tue, Sep 06, 2022 at 12:48:01PM +0200, Jiri Slaby wrote:
> > > This series introduces DEFINE_UART_PORT_TX_HELPER +
> > > DEFINE_UART_PORT_TX_HELPER_LIMITED TX helpers. See PATCH 2/4 for the
> > > details. Comments welcome.
> > >
> > > Then it switches drivers to use them. First, to
> > > DEFINE_UART_PORT_TX_HELPER() in 3/4 and then
> > > DEFINE_UART_PORT_TX_HELPER_LIMITED() in 4/4.
> > >
> > > The diffstat of patches 3+4 is as follows:
> > > 26 files changed, 191 insertions(+), 823 deletions(-)
> > > which appears to be nice.
> >
> > Not really. This is horrid. Quality can't be measured in LoC (only).
> >
> > The resulting code is unreadable. And for no good reason.
>
> IMO, it's much more readable than the original ~ 30 various (and buggy -- see
> Ilpo's fixes) copies of this code. Apart from that, it makes further rework
> much easier (I have switch to kfifo in my mind for example).
>
> > [ And note that you're "saving" something like 20 lines per driver:
>
> It's not about saving, it's about deduplicating and unifying.
>
> > 12 files changed, 84 insertions(+), 349 deletions(-)
> > ]
> >
> > NAK
>
> I'd love to come up with something nicer. That would be a function in
> serial-core calling hooks like I had [1] for example. But provided all those
> CPU workarounds/thunks, it'd be quite expensive to call two functions per
> character.
>
> Or creating a static inline (having ± the macro content) and the hooks as
> parameters and hope for optimizations to eliminate thunks (also suggested in
> the past [1]).
>
> [1] https://lore.kernel.org/all/20220411105405.9519-1-jslaby@suse.cz/
I second Jiri here.
Saving lines in drivers is not that important compared with all removing
all the variants of the same thing that have crept there over the years.
I suspect the main reason for the variants is that everybody just used
other drivers as examples and therefore we've a few "main" variant
branches depending on which of the drivers was used as an example for the
other. That is hardly a good enough reason to keep them different and as
long as each driver keeps its own function for this, it will eventually
lead to similar differentiation so e.g. a one-time band-aid similarization
would not help in the long run.
Also, I don't understand why you see it unreadable when the actual code is
out in the open in that macro. It's formatted much better than e.g.
read_poll_timeout() if you want an example of something that is hardly
readable ;-). I agree though there's a learning-curve, albeit small, that
it actually creates a function but that doesn't seem to me as big of an
obstacle you seem to think.
--
i.
next prev parent reply other threads:[~2022-09-07 10:19 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-06 10:48 [PATCH v3 0/4] tty: TX helpers Jiri Slaby
2022-09-06 10:48 ` [PATCH v3 1/4] tty: serial: move and cleanup vt8500_tx_empty() Jiri Slaby
2022-09-06 10:48 ` [PATCH v3 2/4] tty: serial: introduce transmit helper generators Jiri Slaby
2022-09-06 10:48 ` [PATCH v3 3/4] tty: serial: use DEFINE_UART_PORT_TX_HELPER() Jiri Slaby
2022-09-06 10:48 ` [PATCH v3 4/4] tty: serial: use DEFINE_UART_PORT_TX_HELPER_LIMITED() Jiri Slaby
2022-09-06 11:30 ` [PATCH v3 0/4] tty: TX helpers Johan Hovold
2022-09-07 7:19 ` Jiri Slaby
2022-09-07 10:16 ` Ilpo Järvinen [this message]
2022-09-07 11:59 ` Arnd Bergmann
2022-09-07 12:21 ` Ilpo Järvinen
2022-09-07 12:27 ` Greg Kroah-Hartman
2022-09-07 12:32 ` Ilpo Järvinen
2022-09-07 12:36 ` Greg Kroah-Hartman
2022-09-07 12:56 ` Ilpo Järvinen
2022-09-07 13:47 ` Arnd Bergmann
2022-09-07 13:52 ` Russell King (Oracle)
2022-09-07 14:56 ` Arnd Bergmann
2022-09-09 10:53 ` Jiri Slaby
2022-09-09 11:06 ` Greg Kroah-Hartman
2022-09-09 12:41 ` Johan Hovold
2022-09-09 12:23 ` Johan Hovold
2022-09-09 12:13 ` Johan Hovold
2022-09-07 9:54 ` Ilpo Järvinen
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=4e9b4471-a6f2-4b16-d830-67d253ae4e6a@linux.intel.com \
--to=ilpo.jarvinen@linux.intel.com \
--cc=afaerber@suse.de \
--cc=alexandre.belloni@bootlin.com \
--cc=baolin.wang7@gmail.com \
--cc=bcm-kernel-feedback-list@broadcom.com \
--cc=cernekee@gmail.com \
--cc=claudiu.beznea@microchip.com \
--cc=f.fainelli@gmail.com \
--cc=festevam@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=jirislaby@kernel.org \
--cc=johan@kernel.org \
--cc=kernel@pengutronix.de \
--cc=linux-imx@nxp.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=linux-serial@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=liviu.dudau@arm.com \
--cc=lorenzo.pieralisi@arm.com \
--cc=mani@kernel.org \
--cc=nicolas.ferre@microchip.com \
--cc=orsonzhai@gmail.com \
--cc=pali@kernel.org \
--cc=palmer@dabbelt.com \
--cc=patrice.chotard@foss.st.com \
--cc=paul.walmsley@sifive.com \
--cc=richard.genoud@gmail.com \
--cc=s.hauer@pengutronix.de \
--cc=shawnguo@kernel.org \
--cc=sudeep.holla@arm.com \
--cc=tklauser@distanz.ch \
--cc=vz@mleia.com \
--cc=zhang.lyra@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).