Seeking advice on "monkey patching" a driver

[Greg KH]

On Thu, Jul 01, 2021 at 03:03:12PM -0500, Ian Pilcher wrote:
> On 7/1/21 12:59 PM, Greg KH wrote:
> > Oh that's horrible, please no, do not do that :)
> 
> Indeed it is, but it works, and it meets my main objective, which is to
> allow the use of distribution kernel packages and modules.
> 
> > How about a third option, the correct one:
> > 	- submit your code changes upstream and they get merged into the
> > 	  main kernel tree and no monkeypatching is ever needed at all!
> > 
> > Have you submitted your changes upstream to the existing drivers?  What
> > is preventing that from happening today?
> 
> There are a couple of reasons that I've never attempted to do this.
> 
> * Scope of work - Currently, there is simply no mechanism to call an LED
>   trigger from the ahci or libahci modules, presumably because this is
>   something that  really ought to be done by the hardware.  So I would
>   have to add some sort of generic framework to associate LED triggers
>   with AHCI ports.
> 
>   I probably also don't really have the knowledge to do this.  I am not
>   familiar with locking, memory management, etc. in the kernel.  Just
>   because my "hack" works on a specific 2-core NAS doesn't mean that it
>   won't cause all sorts of breakage on a higher-performance system with
>   more parallelism.

Why are ahci devices somehow "special" here?  Just add a trigger to the
ahci core for LEDs and all should "just work".  We've done that for many
subsystems already.

> * (Probable) lack of upstream interest - As I mentioned, disk activity
>   LEDs really ought to be handled by the hardware.  I don't know of any
>   other system that suffers from this particular limitation.  So this
>   is a very, very niche use case.  (Most users of this hardware use the
>   manufacturer's "firmware".)

Are you sure we don't already have LED triggers for disk activity?  Have
you tried the ledtrig-disk.c driver?  It says it works on ATA devices,
no reason it can't also work for other device types.

>   I did ask about this on the linux-ide mailing list long ago when I
>   first wrote the modules, but I don't think that I ever received a
>   response, which reinforces my belief that upstream isn't likely to be
>   receptive.
> 
> I've invested significant time in kernel patches in the past, only to
> see them ultimately not be accepted, so I would need to know that
> upstream was truly interested in such a feature before I would consider
> making such a commitment.

That's not fair, there is no way anyone can promise anyone that their
patches will be accepted, _before_ anyone sees them.  What would _you_
do if you were in the kernel maintainer's position and read something
like this?

good luck!

greg k-h