[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.
On Fri, Jul 5, 2019 at 8:21 AM Tobin C. Harding <me@tobin.cc> 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 Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
On Fri, Jul 5, 2019 at 9:02 AM Amit Kumar <free.amit.kumar@gmail.com> wrote:
On Fri, Jul 5, 2019 at 8:21 AM Tobin C. Harding <me@tobin.cc> 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 Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
On Fri, Jul 05, 2019 at 10:40:43AM +0530, Amit Kumar wrote:
On Fri, Jul 5, 2019 at 9:02 AM Amit Kumar <free.amit.kumar@gmail.com> wrote:
On Fri, Jul 5, 2019 at 8:21 AM Tobin C. Harding <me@tobin.cc> 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.
Hi, On Fri, Jul 5, 2019 at 4:51 AM Tobin C. Harding <me@tobin.cc> 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 Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
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
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
Hi, I think now your tutorial should be ready. Regards, Amit Kumar On Mon, Jul 22, 2019 at 2:59 PM Tobin C. Harding <me@tobin.cc> 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 devel@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
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.
On Mon, Sep 2, 2019, 07:21 Tobin C. Harding <me@tobin.cc> 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
Thank you very much. I'll go through it and expect it will help me in fulfilling my long aspiring will of being a Linux kernel developer.
Cheers, Tobin.
On Mon, Sep 2, 2019 at 4:52 AM Tobin C. Harding <me@tobin.cc> 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
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.
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.
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
On Mon, Sep 2, 2019 at 5:09 PM Valdis Klētnieks <valdis.kletnieks@vt.edu> 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.
participants (6)
-
Amit Kumar -
Anatoly Pugachev -
Dan Carpenter -
loïc tourlonias -
Tobin C. Harding -
Valdis Klētnieks