From: me@tobin.cc (Tobin C. Harding)
To: kernelnewbies@lists.kernelnewbies.org
Subject: ks7010 cfg80211 re-write
Date: Mon, 26 Jun 2017 11:24:11 +1000 [thread overview]
Message-ID: <20170626012411.GA10047@eros> (raw)
In-Reply-To: <20170623141906.GA1032@kroah.com>
On Fri, Jun 23, 2017 at 10:19:06PM +0800, Greg KH wrote:
> On Thu, Jun 22, 2017 at 11:10:47AM +1000, Tobin C. Harding wrote:
> > May I please ask two questions relating to the correct kernel development
> > protocol to follow for the cfg80211 re-write.
> >
> > Current state: Functional WEXT driver in drivers/staging.
> >
> > Interim state: Partial cfg80211 implementation.
> >
> > Target state: Functional cfg80211 driver in drivers/staging.
> >
> > Future state: Functional cfg80211 driver out of staging.
> >
> > Question 1: Is it correct kernel development protocol to do the
> > interim state in public?
>
> I don't know exactly what you mean by "interm state" here, does the
> driver still work at that point in time?
>
> The rule is, the driver needs to keep working for every patch submitted
> along the way. If you are going to have to break that with the rework,
> then no, that's not ok.
Thanks for clarifying Greg.
> I think many many months ago I said that doing this type of conversion
> for a wifi driver was really hard. It's only ever happened one time in
> the past, and I was amazed at the work involved in doing it.
Yes you did, I did not fully understand you then, I do now.
> Every other time a wifi driver has moved out of staging, the author has
> just given up on the staging driver, and rewritten it "properly" and
> gotten that rewrite merged as one patch, into the real part of the
> kernel, and after that is merged, we delete the staging driver.
>
> Doing it that way is _much_ easier for the developer, as you don't have
> to deal with any interm state at all, you can tear the thing apart and
> put it back together on your own, and just submit the end result.
>
> I strongly recommend doing it this way, but it's up to you in the end :)
I will follow your advice. I am not totally clear on the path into the
kernel once I have a re-written functional driver but let's cross that
bridge when we get to it.
> good luck, and I hope this helps,
Yes, thank you, this helps me.
Tobin.
next prev parent reply other threads:[~2017-06-26 1:24 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-22 1:10 ks7010 cfg80211 re-write Tobin C. Harding
2017-06-23 14:19 ` Greg KH
2017-06-26 1:24 ` Tobin C. Harding [this message]
2017-06-26 4:56 ` Greg KH
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=20170626012411.GA10047@eros \
--to=me@tobin.cc \
--cc=kernelnewbies@lists.kernelnewbies.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.