Hello team , Sorry for a vague question. So far I have spent a lot of time dreaming to be a kernel hacker without doing much , but I realised its geting too late and now I want to pick my first patch to work, I have decided to address the TODO at drivers/staging/grebus/TODO : " * Make pwm.c use the struct pwm_ops::apply instead of ::config, ::set_polarity, 4 ::enable and ::disable." To make sure this is a first good patch , I verified that there is traction for this driver recently. But I am not sure, let's say I change the code , how to test it ? Any thoughts on whether I should just do a checkpatch.pl change as my first patch ? Thanks Vardhan
On Sun, Mar 21, 2021 at 12:03:36PM -0400, Harsha Vardhan wrote:
Any thoughts on whether I should just do a checkpatch.pl change as my first patch ?
You should do a checkpatch.pl change as your first patch :) That way you can focus on the process more than the technical aspects of the patch (git, changelog text, subject line, email, submission, revision, acceptance, etc.) and not have to worry a lot about breaking working code or not. After you get the process working properly for you, then move to changing real code and contributing that way. But that's just a suggestion, not a requirement, you can do whatever you want to do :) good luck! greg k-h
perfect ! I will do it that way then. besides that, generally if you are making changes to drivers , then the responsibility of testing is on the author of the patch right ? if you don't have the device how would you test such things ? I would assume other subsystems like memory will have some sort of test suite that gets run automatically to make sure we are not introducing any regressions but confused as to how we ensure the same with drivers. Thanks so much Greg , for a quick reply . On Sun, Mar 21, 2021 at 12:14 PM Greg KH <greg@kroah.com> wrote:
On Sun, Mar 21, 2021 at 12:03:36PM -0400, Harsha Vardhan wrote:
Any thoughts on whether I should just do a checkpatch.pl change as my first patch ?
You should do a checkpatch.pl change as your first patch :)
That way you can focus on the process more than the technical aspects of the patch (git, changelog text, subject line, email, submission, revision, acceptance, etc.) and not have to worry a lot about breaking working code or not.
After you get the process working properly for you, then move to changing real code and contributing that way.
But that's just a suggestion, not a requirement, you can do whatever you want to do :)
good luck!
greg k-h
On Sun, Mar 21, 2021 at 5:25 PM Harsha Vardhan <harshavardhan3294@gmail.com> wrote:
perfect ! I will do it that way then.
besides that, generally if you are making changes to drivers , then the responsibility of testing is on the author of the patch right ? if you don't have the device how would you test such things ? I would assume other subsystems like memory will have some sort of test suite that gets run automatically to make sure we are not introducing any regressions but confused as to how we ensure the same with drivers.
You already violated the first rule of email netiquette. Do not top post. See more here https://people.kernel.org/tglx/notes-about-netiquette. To your question: It is not required that you have the driver at hand when you make changes. That requirement would make any larger refactoring impossible. You should be able to argue that the change you made is reasonable and does not break any driver that was not already broken before. It is up to the users and driver maintainers to ensure that drivers continue working... Start with some checkpatch fix on staging... and then you will see... Lukas
On Sun, 21 Mar 2021 12:03:36 -0400, Harsha Vardhan said:
So far I have spent a lot of time dreaming to be a kernel hacker without doing much ,
1) What Greg said.. :) 2) Go read this: https://lists.kernelnewbies.org/pipermail/kernelnewbies/2017-April/017765.ht... And yes, *why* you want to be a kernel hacker matters. :)
participants (4)
-
Greg KH -
Harsha Vardhan -
Lukas Bulwahn -
Valdis Klētnieks