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

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

On Wed, Feb 5, 2020 at 11:18 PM Finn Thain [off-list ref]  wrote:

quoted

On Wed, 5 Feb 2020, Philippe Mathieu-Daudé wrote:

quoted

On Sun, Feb 2, 2020 at 3:41 AM Finn Thain  [off-list ref] wrote:

quoted

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.

quoted

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".