ks7010 cfg80211 re-write
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.
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
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.
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
participants (2)
-
Greg KH -
Tobin C. Harding