[PATCH 1/3] fbdev/g364fb: Fix build failure

[Finn Thain]

On Fri, 7 Feb 2020, Philippe Mathieu-Daudé wrote:

> On Wed, Feb 5, 2020 at 11:18 PM Finn Thain <fthain at 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 at 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".