ks7010 cfg80211 re-write

ks7010 cfg80211 re-write

[Tobin C. Harding]

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?

 - If NO -> end of email.

 - If YES;

Question 2: What is the correct directory structure to have in the interim?

1. Remove WEXT code entirely, substitute in progress cfg80211 code.

2. Move WEXT code to sub directory and remove from build process.

3. Add cfg80211 drive as a new, separate driver, enable kernel
   configuration for WEXT and cfg80211 as separate drivers.

4. Add cfg80211 code as sub directory keeping functioning WEXT driver
   in place.

5. Other


I don't see how option 3 or 4 are possible and/or sensible.


thanks,
Tobin.

ks7010 cfg80211 re-write

[Greg KH]

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.

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.

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 :)

good luck, and I hope this helps,

greg k-h

ks7010 cfg80211 re-write

[Tobin C. Harding]

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.

ks7010 cfg80211 re-write

[Greg KH]

On Mon, Jun 26, 2017 at 11:24:11AM +1000, Tobin C. Harding wrote:
> > 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.

Just submit a patch adding your new driver to
drivers/net/wireless/somewhere... to the correct mailing list, and all
will be fine.  When that gets accepted, let me know by either just
emailing me, or sending me a patch to delete the old driver out of
staging.

good luck, and see you in LA!

greg k-h