From: Finn Thain <fthain@telegraphics.com.au>
To: "Philippe Mathieu-Daudé" <f4bug@amsat.org>
Cc: linux-fbdev@vger.kernel.org,
Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
Paul Burton <paulburton@kernel.org>,
Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>,
James Hogan <jhogan@kernel.org>,
open list <linux-kernel@vger.kernel.org>,
Ralf Baechle <ralf@linux-mips.org>,
"open list:BROADCOM NVRAM DRIVER" <linux-mips@vger.kernel.org>,
Thomas Bogendoerfer <tbogendoerfer@suse.de>,
dri-devel@lists.freedesktop.org,
Laurent Vivier <laurent@vivier.eu>
Subject: Re: [PATCH 1/3] fbdev/g364fb: Fix build failure
Date: Fri, 07 Feb 2020 00:10:21 +0000 [thread overview]
Message-ID: <alpine.LNX.2.22.394.2002071054180.13@nippy.intranet> (raw)
In-Reply-To: <CAAdtpL5Cz5YGKZVfbA=X8qMtP7jDc0G7igSj3EB=PfazM5JoDg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3132 bytes --]
On Fri, 7 Feb 2020, Philippe Mathieu-Daudé wrote:
> On Wed, Feb 5, 2020 at 11:18 PM Finn Thain <fthain@telegraphics.com.au> wrote:
> > On Wed, 5 Feb 2020, Philippe Mathieu-Daudé wrote:
> > > On Sun, Feb 2, 2020 at 3:41 AM Finn Thain <fthain@telegraphics.com.au> wrote:
> > > >
> > > > This patch resolves these compiler errors and warnings --
> > > >
> > > > CC drivers/video/fbdev/g364fb.o
> > > > drivers/video/fbdev/g364fb.c: In function 'g364fb_cursor':
> > > > drivers/video/fbdev/g364fb.c:137:9: error: 'x' undeclared (first use in this function)
> > > > drivers/video/fbdev/g364fb.c:137:9: note: each undeclared identifier is reported only once for each function it appears in
> > > > drivers/video/fbdev/g364fb.c:137:7: error: implicit declaration of function 'fontwidth' [-Werror=implicit-function-declaration]
> > > > drivers/video/fbdev/g364fb.c:137:23: error: 'p' undeclared (first use in this function)
> > > > drivers/video/fbdev/g364fb.c:137:38: error: 'y' undeclared (first use in this function)
> > > > drivers/video/fbdev/g364fb.c:137:7: error: implicit declaration of function 'fontheight' [-Werror=implicit-function-declaration]
> > > > drivers/video/fbdev/g364fb.c: In function 'g364fb_init':
> > > > drivers/video/fbdev/g364fb.c:233:24: error: 'fbvar' undeclared (first use in this function)
> > > > drivers/video/fbdev/g364fb.c:234:24: error: 'xres' undeclared (first use in this function)
> > >
> > > 18 years unnoticed...
> > >
> >
> > More likely, it was noticed by those without the skills or time to get
> > it fixed upstream.
> >
> > Those with the hardware skills and platform knowledge to be affected
> > by an obscure bug aren't necessarily also capable of fixing a kernel
> > bug, sending a patch upstream and getting it past code review.
> >
> > Getting a patch into the Linux kernel is itself a lot of work, unless
> > you've had years of experience with that constantly changing process
> > (which varies significantly between subsystems).
>
> I see, I'm not custom to kernel workflow.
>
> > Kernel developers are only human and do accidentally introduce
> > breakage in their work (as contributors) while ironically (as
> > reviewers) they raise the bar for random fixes from users not versed
> > in the 10000+ lines of Documentation/process/*.rst
> >
> > Broken code does not mean zero potential users or zero frustrated
> > users yet I often hear kernel developers disingenuously claim that it
> > does. They have an incentive to make that claim and often there's
> > no-one reading the mailing lists to push back.
>
> But broken code is also bad example of code. The removed code is still
> buried in the git tree.
>
Some bugs may never be noticed and yet everyone assumes that they are
present (hence "defence in depth" and all of the complexity that entails).
My complaint was really about broken code being used as a rationale to
remove additional code (whatever its quality).
For example, some maintainers would say, "18 years unnoticed... don't stop
at g364fb_cursor(), remove the entire driver".
prev parent reply other threads:[~2020-02-07 0:10 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-02 2:33 [PATCH 0/3] Improve MIPS Magnum support Finn Thain
2020-02-02 2:33 ` [PATCH 1/3] fbdev/g364fb: Fix build failure Finn Thain
2020-02-05 18:02 ` Philippe Mathieu-Daudé
2020-02-05 18:19 ` Philippe Mathieu-Daudé
2020-02-05 22:18 ` Finn Thain
2020-02-05 22:17 ` Finn Thain
2020-02-06 23:00 ` Philippe Mathieu-Daudé
2020-02-07 0:10 ` Finn Thain [this message]
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=alpine.LNX.2.22.394.2002071054180.13@nippy.intranet \
--to=fthain@telegraphics.com.au \
--cc=b.zolnierkie@samsung.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=f4bug@amsat.org \
--cc=jhogan@kernel.org \
--cc=laurent@vivier.eu \
--cc=linux-fbdev@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@vger.kernel.org \
--cc=paulburton@kernel.org \
--cc=ralf@linux-mips.org \
--cc=tbogendoerfer@suse.de \
--cc=tsbogend@alpha.franken.de \
/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).