On Thu, Jul 1, 2021 at 2:03 PM Ian Pilcher <arequipeno@xxxxxxxxx> 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 > * (Probable) lack of upstream interest - As I mentioned, disk activity > LEDs really ought to be handled by the hardware. Are LEDs really that important? Unless theyre rigged intrinsically into the operation, it seems tertiary 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".) > > 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. > theres a firehose of patches. FWIW, now robots watch the list, and will grind your patches on lots of configs. arches > 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. > no guarantees, but there is staging. (here, more or less) provisional home for code while quality develops once youre in-tree, warts and all (to some extent, I dont know) you may well get help (patches) improving it, surely lots of feedback. elsewhere, nobody knows it exists.
