From: Greg KH <greg@kroah.com>
To: Ian Pilcher <arequipeno@gmail.com>
Cc: linux-modules@vger.kernel.org, kernelnewbies@kernelnewbies.org
Subject: Re: Seeking advice on "monkey patching" a driver
Date: Fri, 2 Jul 2021 14:20:09 +0200 [thread overview]
Message-ID: <YN8EecLokJuHrptR@kroah.com> (raw)
In-Reply-To: <5c34419f-ef7d-a9bd-0c90-c77e2526b739@gmail.com>
On Fri, Jul 02, 2021 at 07:05:26AM -0500, Ian Pilcher wrote:
> > > 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?
>
> You're right, but that isn't what I intended to say. Basically, I can't
> afford to invest the time in implementing something if the subsystem
> maintainers have no interest in the *functionality*, regardless of the
> state of the code. I.e., if the ATA/LED subsystem maintainers think
> that software-controlled disk activity LEDs are stupid and have no
> place in the kernel, then code quality is irrelevant, and anything I do
> will be a waste of time.
Again, without a real patch, no maintainer or developer will ever say if
they will, or will not, accept such a thing. That's just not how kernel
development works. Working patches are what is discussed as that proves
that at least, the idea works.
thanks,
greg k-h
next prev parent reply other threads:[~2021-07-02 12:20 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-01 16:25 Seeking advice on "monkey patching" a driver Ian Pilcher
2021-07-01 17:59 ` Greg KH
2021-07-01 20:03 ` Ian Pilcher
2021-07-01 21:04 ` jim.cromie
2021-07-02 4:31 ` Greg KH
2021-07-02 12:05 ` Ian Pilcher
2021-07-02 12:20 ` Greg KH [this message]
2021-07-02 15:16 ` Ian Pilcher
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YN8EecLokJuHrptR@kroah.com \
--to=greg@kroah.com \
--cc=arequipeno@gmail.com \
--cc=kernelnewbies@kernelnewbies.org \
--cc=linux-modules@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).