[OSSNA] Intro to kernel hacking tutorial
Hi, I am doing a tutorial at OSSNA in San Diego on getting into kernel hacking. I'm only a couple of years deep into kernel hacking so I wanted to reach out to those more experienced than myself (and those less experienced). Is there any thing that you would really like to see covered in this tutorial? If you are a grey beard is there anything that you have been lamenting us newbies not knowing/doing? If you are a newbie is there anything that you are struggling with that you really want to learn? Current format/content: the tutorial will attempt to bridge the gap in the learning process between the 'first patch' page on kernelnewbies.org wiki and being 'comfortable' patching the kernel via LKML. Outcome will (hopefully) be a small patch set into drivers/staging/. (Don't worry Greg only one group got to this stage last time, you won't get flooded with patches :) Thanks, Tobin. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [OSSNA] Intro to kernel hacking tutorial
Hi, I think now your tutorial should be ready. Regards, Amit Kumar On Mon, Jul 22, 2019 at 2:59 PM Tobin C. Harding wrote: > > On Fri, Jul 19, 2019 at 12:36:58PM +0300, Dan Carpenter wrote: > > On Fri, Jul 05, 2019 at 12:50:55PM +1000, Tobin C. Harding wrote: > > > Outcome will (hopefully) be a small patch set into drivers/staging/. > > > (Don't worry Greg only one group got to this stage last time, you > > > won't get flooded with patches :) > > > > We're good at reviewing floods of patches. Send away. > > > > In the end what we want is people who will take over a driver and > > understand it completely and become the maintainer. We've had a few > > people that did appointed themselves to become the maintainer of a > > random driver and move it out of staging. But even if people don't make > > it all the way to become a maintainer, it's nice when they start down > > that path by focusing on one driver and trying to understand it as much > > as possible. > > > > Most of the time when you look at a new staging driver, then you do want > > to clean up the white space just because it's hard to look at > > non-standard code. So that's the first step. But then maybe start at > > the probe and release functions and clean it up. Keep your eyes open > > to any other mistakes or bugs you see. Write them down. Then the > > ioctls. Etc. Look at the TODO too. > > > > The other thing I wish people knew was about the relationship with > > maintainers. When you start out, you're virtually anonymous for the > > first couple patchsets. We get so many and they blend together so we > > don't remember your name. So don't think that we mean anything > > personally if we don't apply your patch. We have forgotten about the > > patch as soon as we reply to it. Don't panic and resend quickly. You > > will be too stressed. Wait until the next day. > > > > In staging we really want to apply patches (unless it's in staging > > because we're going to remove the code). I get annoyed with other > > staging reviewers who NAK patches because "I don't like churn" or > > whatever. > > > > On the other hand, patches just "silencing checkpatch.pl" is not a valid > > justification for sending a patch. Patches should make the code more > > readable. > > > > Anyway, maintainers are not monsters. Very few people have made me > > annoyed to the point where I refuse to review their code. And everyone > > else is in my good books so that's fine. > > Cool, points noted. Thanks Dan > > > Tobin > ___ > devel mailing list > de...@linuxdriverproject.org > http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [OSSNA] Intro to kernel hacking tutorial
On Sun, Sep 01, 2019 at 05:30:23AM +0530, Amit Kumar wrote: > Hi, > I think now your tutorial should be ready. I do not understand what this means sorry. Is it a request for action? The tutorial was a couple of weeks ago now, here is a link to the material if that is what you were asking https://github.com/tcharding/kernel/tree/master/workshop Cheers, Tobin. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [OSSNA] Intro to kernel hacking tutorial
On Mon, Sep 2, 2019 at 4:52 AM Tobin C. Harding wrote: > > On Sun, Sep 01, 2019 at 05:30:23AM +0530, Amit Kumar wrote: > > Hi, > > I think now your tutorial should be ready. > > I do not understand what this means sorry. Is it a request for action? > The tutorial was a couple of weeks ago now, here is a link to the > material if that is what you were asking > > https://github.com/tcharding/kernel/tree/master/workshop Tobin, is it intentionally that you use yes "" | make oldconfig instead of make olddefconfig in some of your docs ? ( tutorial/cheat-sheet.rst , tutorial/trouble-shoot.rst ) Want me to create/submit PR on github with 'make olddefconfig' ? Thanks. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [OSSNA] Intro to kernel hacking tutorial
On Mon, 02 Sep 2019 15:42:19 +0300, Anatoly Pugachev said: > is it intentionally that you use > > yes "" | make oldconfig > > instead of > > make olddefconfig They do something different. 'olddefconfig' just takes the platform or architecture defconfig and updates it for any new CONFIG_* variables added since the last time the defconfig was updated in the tree. yes "" | make oldconfig does the same updating for new CONFIG_* variables, but starts with the most recent .config - which produces wildly different results if the .config had previously been minimized by 'make localmodconfig' or other similar techniques. pgpdEh0DaI1xZ.pgp Description: PGP signature ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [OSSNA] Intro to kernel hacking tutorial
On Mon, Sep 02, 2019 at 10:08:54AM -0400, Valdis Klētnieks wrote: > On Mon, 02 Sep 2019 15:42:19 +0300, Anatoly Pugachev said: > > > is it intentionally that you use > > > > yes "" | make oldconfig > > > > instead of > > > > make olddefconfig > > They do something different. 'olddefconfig' just takes the platform or > architecture defconfig and updates it for any new CONFIG_* variables added > since the last time the defconfig was updated in the tree. > > yes "" | make oldconfig does the same updating for new CONFIG_* variables, > but > starts with the most recent .config - which produces wildly different results > if the .config had previously been minimized by 'make localmodconfig' or other > similar techniques. Thanks Valdis, you're the man! Tobin signature.asc Description: PGP signature ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [OSSNA] Intro to kernel hacking tutorial
On Mon, Sep 2, 2019 at 5:09 PM Valdis Klētnieks wrote: > > On Mon, 02 Sep 2019 15:42:19 +0300, Anatoly Pugachev said: > > > is it intentionally that you use > > > > yes "" | make oldconfig > > > > instead of > > > > make olddefconfig > > They do something different. 'olddefconfig' just takes the platform or > architecture defconfig and updates it for any new CONFIG_* variables added > since the last time the defconfig was updated in the tree. > > yes "" | make oldconfig does the same updating for new CONFIG_* variables, > but > starts with the most recent .config - which produces wildly different results > if the .config had previously been minimized by 'make localmodconfig' or other > similar techniques. Maybe i don't understand something, but someone would probably want to patch kernel 'make help' accordingly , since current one lists: $ make help oldconfig - Update current config utilising a provided .config as base olddefconfig- Same as oldconfig but sets new symbols to their default value without prompting Thanks. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [OSSNA] Intro to kernel hacking tutorial
On Fri, Jul 5, 2019 at 8:21 AM Tobin C. Harding wrote: > > Hi, > > I am doing a tutorial at OSSNA in San Diego on getting into kernel > hacking. I'm only a couple of years deep into kernel hacking so I > wanted to reach out to those more experienced than myself (and those > less experienced). > > Is there any thing that you would really like to see covered in this > tutorial? > > If you are a grey beard is there anything that you have been lamenting > us newbies not knowing/doing? > > If you are a newbie is there anything that you are struggling with that > you really want to learn? Thank you. Where can I find your tutorial? Regards, Amit Kumar > Current format/content: the tutorial will attempt to bridge the gap in > the learning process between the 'first patch' page on kernelnewbies.org > wiki and being 'comfortable' patching the kernel via LKML. Outcome will > (hopefully) be a small patch set into drivers/staging/. (Don't worry > Greg only one group got to this stage last time, you won't get flooded > with patches :) > > Thanks, > Tobin. > > ___ > Kernelnewbies mailing list > kernelnewb...@kernelnewbies.org > https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [OSSNA] Intro to kernel hacking tutorial
On Fri, Jul 5, 2019 at 9:02 AM Amit Kumar wrote: > > On Fri, Jul 5, 2019 at 8:21 AM Tobin C. Harding wrote: > > > > Hi, > > > > I am doing a tutorial at OSSNA in San Diego on getting into kernel > > hacking. I'm only a couple of years deep into kernel hacking so I > > wanted to reach out to those more experienced than myself (and those > > less experienced). > > > > Is there any thing that you would really like to see covered in this > > tutorial? > > > > If you are a grey beard is there anything that you have been lamenting > > us newbies not knowing/doing? > > > > If you are a newbie is there anything that you are struggling with that > > you really want to learn? > Thank you. > Where can I find your tutorial? I forget to tell, merely creating and sending patches is not important. Also I would like to know how to manage patches, using git, mutt, quilt and so on. Sending patch through git-email is good. But different versions of patch. Applying patch from mutt. Replying to patch recipients. > Regards, > Amit Kumar > > > Current format/content: the tutorial will attempt to bridge the gap in > > the learning process between the 'first patch' page on kernelnewbies.org > > wiki and being 'comfortable' patching the kernel via LKML. Outcome will > > (hopefully) be a small patch set into drivers/staging/. (Don't worry > > Greg only one group got to this stage last time, you won't get flooded > > with patches :) > > > > Thanks, > > Tobin. > > > > ___ > > Kernelnewbies mailing list > > kernelnewb...@kernelnewbies.org > > https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [OSSNA] Intro to kernel hacking tutorial
Hi, On Fri, Jul 5, 2019 at 4:51 AM Tobin C. Harding wrote: > > Hi, > > I am doing a tutorial at OSSNA in San Diego on getting into kernel > hacking. I'm only a couple of years deep into kernel hacking so I > wanted to reach out to those more experienced than myself (and those > less experienced). > > Is there any thing that you would really like to see covered in this > tutorial? > I'm not involved in kernel hacking, but I've tried several times to start writing patches. Because of time sharing issue I haven't get to the end but a tutorial will be great. The question I've asked me during my several tries is where can I be useful (which topics, what I'm confident enough in to play with...). Looking in drivers/staging wasn't any help in my case and making kernel janitor is useful but not very well viewed as I've heard. So I think that digging further in your tutorial on several ways to start kernel hacking may be interesting. > Current format/content: the tutorial will attempt to bridge the gap in > the learning process between the 'first patch' page on kernelnewbies.org > wiki and being 'comfortable' patching the kernel via LKML. Outcome will > (hopefully) be a small patch set into drivers/staging/. (Don't worry > Greg only one group got to this stage last time, you won't get flooded > with patches :) > HTH and very enthusiast to read this tutorial. Loïc > Thanks, > Tobin. > > ___ > Kernelnewbies mailing list > kernelnewb...@kernelnewbies.org > https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [OSSNA] Intro to kernel hacking tutorial
On Fri, Jul 05, 2019 at 10:40:43AM +0530, Amit Kumar wrote: > On Fri, Jul 5, 2019 at 9:02 AM Amit Kumar wrote: > > > > On Fri, Jul 5, 2019 at 8:21 AM Tobin C. Harding wrote: > > > > > > Hi, > > > > > > I am doing a tutorial at OSSNA in San Diego on getting into kernel > > > hacking. I'm only a couple of years deep into kernel hacking so I > > > wanted to reach out to those more experienced than myself (and those > > > less experienced). > > > > > > Is there any thing that you would really like to see covered in this > > > tutorial? > > > > > > If you are a grey beard is there anything that you have been lamenting > > > us newbies not knowing/doing? > > > > > > If you are a newbie is there anything that you are struggling with that > > > you really want to learn? > > Thank you. > > Where can I find your tutorial? It's not written yet :) > I forget to tell, merely creating and sending patches is not important. > Also I would like to know how to manage patches, using git, mutt, quilt > and so on. > Sending patch through git-email is good. But different versions of patch. > Applying patch from mutt. Replying to patch recipients. Nice suggestions thanks, will work this in. thanks, Tobin. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [OSSNA] Intro to kernel hacking tutorial
On Fri, Jul 05, 2019 at 12:50:55PM +1000, Tobin C. Harding wrote: > Outcome will (hopefully) be a small patch set into drivers/staging/. > (Don't worry Greg only one group got to this stage last time, you > won't get flooded with patches :) We're good at reviewing floods of patches. Send away. In the end what we want is people who will take over a driver and understand it completely and become the maintainer. We've had a few people that did appointed themselves to become the maintainer of a random driver and move it out of staging. But even if people don't make it all the way to become a maintainer, it's nice when they start down that path by focusing on one driver and trying to understand it as much as possible. Most of the time when you look at a new staging driver, then you do want to clean up the white space just because it's hard to look at non-standard code. So that's the first step. But then maybe start at the probe and release functions and clean it up. Keep your eyes open to any other mistakes or bugs you see. Write them down. Then the ioctls. Etc. Look at the TODO too. The other thing I wish people knew was about the relationship with maintainers. When you start out, you're virtually anonymous for the first couple patchsets. We get so many and they blend together so we don't remember your name. So don't think that we mean anything personally if we don't apply your patch. We have forgotten about the patch as soon as we reply to it. Don't panic and resend quickly. You will be too stressed. Wait until the next day. In staging we really want to apply patches (unless it's in staging because we're going to remove the code). I get annoyed with other staging reviewers who NAK patches because "I don't like churn" or whatever. On the other hand, patches just "silencing checkpatch.pl" is not a valid justification for sending a patch. Patches should make the code more readable. Anyway, maintainers are not monsters. Very few people have made me annoyed to the point where I refuse to review their code. And everyone else is in my good books so that's fine. regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [OSSNA] Intro to kernel hacking tutorial
On Fri, Jul 19, 2019 at 12:36:58PM +0300, Dan Carpenter wrote: > On Fri, Jul 05, 2019 at 12:50:55PM +1000, Tobin C. Harding wrote: > > Outcome will (hopefully) be a small patch set into drivers/staging/. > > (Don't worry Greg only one group got to this stage last time, you > > won't get flooded with patches :) > > We're good at reviewing floods of patches. Send away. > > In the end what we want is people who will take over a driver and > understand it completely and become the maintainer. We've had a few > people that did appointed themselves to become the maintainer of a > random driver and move it out of staging. But even if people don't make > it all the way to become a maintainer, it's nice when they start down > that path by focusing on one driver and trying to understand it as much > as possible. > > Most of the time when you look at a new staging driver, then you do want > to clean up the white space just because it's hard to look at > non-standard code. So that's the first step. But then maybe start at > the probe and release functions and clean it up. Keep your eyes open > to any other mistakes or bugs you see. Write them down. Then the > ioctls. Etc. Look at the TODO too. > > The other thing I wish people knew was about the relationship with > maintainers. When you start out, you're virtually anonymous for the > first couple patchsets. We get so many and they blend together so we > don't remember your name. So don't think that we mean anything > personally if we don't apply your patch. We have forgotten about the > patch as soon as we reply to it. Don't panic and resend quickly. You > will be too stressed. Wait until the next day. > > In staging we really want to apply patches (unless it's in staging > because we're going to remove the code). I get annoyed with other > staging reviewers who NAK patches because "I don't like churn" or > whatever. > > On the other hand, patches just "silencing checkpatch.pl" is not a valid > justification for sending a patch. Patches should make the code more > readable. > > Anyway, maintainers are not monsters. Very few people have made me > annoyed to the point where I refuse to review their code. And everyone > else is in my good books so that's fine. Cool, points noted. Thanks Dan Tobin ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel