Seeking advice on "monkey patching" a driver
arequipeno at gmail.com
Thu Jul 1 16:03:12 EDT 2021
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
* (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
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
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.
In Soviet Russia, Google searches you!
More information about the Kernelnewbies