[OSSNA] Intro to kernel hacking tutorial

[OSSNA] Intro to kernel hacking tutorial

[Tobin C. Harding]

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.

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: [OSSNA] Intro to kernel hacking tutorial

[Amit Kumar]

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
_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [OSSNA] Intro to kernel hacking tutorial

[Amit Kumar]

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
_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [OSSNA] Intro to kernel hacking tutorial

[loïc tourlonias]

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
_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [OSSNA] Intro to kernel hacking tutorial

[Tobin C. Harding]

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.

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

[OSSNA] Intro to kernel hacking tutorial

[Dan Carpenter]

On Fri, Jul 05, 2019@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

[OSSNA] Intro to kernel hacking tutorial

[Tobin C. Harding]

On Fri, Jul 19, 2019@12:36:58PM +0300, Dan Carpenter wrote:
> On Fri, Jul 05, 2019@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

Re: [OSSNA] Intro to kernel hacking tutorial

[Amit Kumar]

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
_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [OSSNA] Intro to kernel hacking tutorial

[Tobin C. Harding]

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
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [OSSNA] Intro to kernel hacking tutorial

[Anatoly Pugachev]

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
>
> 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
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [OSSNA] Intro to kernel hacking tutorial

[Valdis Klētnieks]

[-- Attachment #1.1: Type: text/plain, Size: 626 bytes --]

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.


[-- Attachment #1.2: Type: application/pgp-signature, Size: 832 bytes --]

[-- Attachment #2: Type: text/plain, Size: 169 bytes --]

_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [OSSNA] Intro to kernel hacking tutorial

[Tobin C. Harding]

[-- Attachment #1.1: Type: text/plain, Size: 803 bytes --]

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



[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 169 bytes --]

_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [OSSNA] Intro to kernel hacking tutorial

[Anatoly Pugachev]

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.
_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel