[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.21.2409102140440.60835@angie.orcam.me.uk>
Date: Tue, 10 Sep 2024 22:03:08 +0100 (BST)
From: "Maciej W. Rozycki" <macro@...am.me.uk>
To: Jiaxun Yang <jiaxun.yang@...goat.com>
cc: Thomas Bogendoerfer <tsbogend@...ha.franken.de>,
"linux-mips@...r.kernel.org" <linux-mips@...r.kernel.org>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] MIPS: kprobes: Massage previous delay slot
detection
On Tue, 10 Sep 2024, Jiaxun Yang wrote:
> >> + if (insn_has_delayslot(prev_insn)) {
> >> + pr_notice("Kprobes for branch delayslot are not supported\n");
> >
> > This now overruns 80 columns making code *less* readable.
>
> I don't really agree, we are not in VGA display era any more, see Linus's
> arguments on removal of 80 columns [1] and why long line are more readable [2].
Human perception hasn't changed though and just that you can squeeze a
vast number of characters in a line it doesn't mean you can parse them
comfortably with eyes. Printed books have a common line length limit too,
established with centuries of experience. Some projects such as GDB
prefer a lower soft limit of 74 characters even (with 80 being the hard
one), exactly for this reason[1].
NB even back in 1990s there was an option to use 132-character lines with
SVGA hardware in text mode, but hardly anybody used that because, well, it
didn't make text any more readable. Rather one became lost right away.
Last but not least Documentation/process/coding-style.rst still mandates
80-column formatting.
References:
[1] <https://sourceware.org/ml/gdb-patches/2014-01/msg00216.html>
Maciej
Powered by blists - more mailing lists