Don't know where to start linux kernel programming
Hi, I'm new to linux kernel programming, I want to be a linux kernel hacker but i don't know where to start. Please help me. Thanks Sunil Khorwal
Hi, On 22.08.2017 12:52, SUNIL KHORWAL wrote:
I'm new to linux kernel programming, I want to be a linux kernel hacker but i don't know where to start. Please help me.
Start from https://kernelnewbies.org/ https://lwn.net/ https://www.kernel.org/ You are using gmail, so this may help: linux/Documentation/process/email-clients.rst or http://elixir.free-electrons.com/linux/v4.13-rc6/source/Documentation/proces... http://elixir.free-electrons.com/linux/v4.13-rc6/source/Documentation/proces... There is eudyptula challange (currently busy, no new subscriptions) and there is note about [not] using gmail for kernel: https://events.linuxfoundation.org/sites/events/files/slides/ec.pdf -- Best regards, Kamil Konieczny Samsung R&D Institute Poland
Thank you very much. :) On Tue, Aug 22, 2017 at 4:44 PM, Kamil Konieczny < k.konieczny@partner.samsung.com> wrote:
Hi,
On 22.08.2017 12:52, SUNIL KHORWAL wrote:
I'm new to linux kernel programming, I want to be a linux kernel hacker but i don't know where to start. Please help me.
Start from https://kernelnewbies.org/ https://lwn.net/ https://www.kernel.org/
You are using gmail, so this may help:
linux/Documentation/process/email-clients.rst
or
http://elixir.free-electrons.com/linux/v4.13-rc6/source/ Documentation/process http://elixir.free-electrons.com/linux/v4.13-rc6/source/ Documentation/process/email-clients.rst
There is eudyptula challange (currently busy, no new subscriptions) and there is note about [not] using gmail for kernel:
https://events.linuxfoundation.org/sites/events/files/slides/ec.pdf
-- Best regards, Kamil Konieczny Samsung R&D Institute Poland
On Tue, Aug 22, 2017 at 04:45:29PM +0530, SUNIL KHORWAL wrote:
Thank you very much. :)
Friendly lesson number 1: don't top post when replying to email on a kernel mailing list.
On Tue, Aug 22, 2017 at 4:44 PM, Kamil Konieczny < k.konieczny@partner.samsung.com> wrote:
Hi,
On 22.08.2017 12:52, SUNIL KHORWAL wrote:
I'm new to linux kernel programming, I want to be a linux kernel hacker but i don't know where to start. Please help me.
Start from https://kernelnewbies.org/ https://lwn.net/ https://www.kernel.org/
You are using gmail, so this may help:
linux/Documentation/process/email-clients.rst
or
http://elixir.free-electrons.com/linux/v4.13-rc6/source/ Documentation/process http://elixir.free-electrons.com/linux/v4.13-rc6/source/ Documentation/process/email-clients.rst
There is eudyptula challange (currently busy, no new subscriptions) and there is note about [not] using gmail for kernel:
https://events.linuxfoundation.org/sites/events/files/slides/ec.pdf
-- Best regards, Kamil Konieczny Samsung R&D Institute Poland
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
On 8/22/17, Kamil Konieczny <k.konieczny@partner.samsung.com> wrote:
Hi,
On 22.08.2017 12:52, SUNIL KHORWAL wrote:
I'm new to linux kernel programming, I want to be a linux kernel hacker but i don't know where to start. Please help me.
Start from https://kernelnewbies.org/ https://lwn.net/ https://www.kernel.org/
You are using gmail, so this may help:
linux/Documentation/process/email-clients.rst
or
http://elixir.free-electrons.com/linux/v4.13-rc6/source/Documentation/proces... http://elixir.free-electrons.com/linux/v4.13-rc6/source/Documentation/proces...
There is eudyptula challange (currently busy, no new subscriptions) and there is note about [not] using gmail for kernel:
https://events.linuxfoundation.org/sites/events/files/slides/ec.pdf
Hi.. I'm pretty sure this is my first post. I found you all about a week ago. I've been using computers since 1994, but I have cognitive issues that give me the ongoing insight of a newbie every day. I actually consider that a win because you never forget what it's like to be a newbie. :) I'm just starting this whole process, too. For me, the first thing I wanted to do was compile the newest stable kernel on my pre-existing Debian Buster (testing) setup. I spent... like an hour last night just trying to find a how-to that my brain could comprehend. I finally ended up back at kernelnewbies k/t the right keywords in a search: https://kernelnewbies.org/KernelBuild I'm at the "Duplicating your current config" step which is the one I'll use for my first attempt at all this. An observation that may just mean I haven't stumbled upon it yet is that it would be nice to... stumble upon... a list of kernel problems that *kernelnewbies* could cut their teeth on. I do understand that this is a naive wish list item due to the nearly every nanosecond changing complexity of things. :) People come in wanting to help but don't always have an end target project in mind. Some more sleuthing on the Net (for "list of current linux kernel bugs") showed others asking for the same thing over the years. That search successfully landed these potential starting points in our search for where to apply our energies: * https://bugzilla.kernel.org/ * http://vger.kernel.org/vger-lists.html#linux-kernel sample: https://marc.info/?l=linux-kernel Approximate 20,000 emails *per month*. That's a lot of studying up to do. I'll see you all out there. :) Cindy :) PS My apologies in advance if I initially flub things related to certain parts of emailing this list. Like starting with this email, I've culled some of the reply-to because I assume you all are already directly following this mailing list. :) -- Cindy-Sue Causey Talking Rock, Pickens County, Georgia, USA * runs with duct tape *
On Tue, 22 Aug 2017 12:48:42 -0400, Cindy-Sue Causey said:
An observation that may just mean I haven't stumbled upon it yet is that it would be nice to... stumble upon... a list of kernel problems that *kernelnewbies* could cut their teeth on. I do understand that this is a naive wish list item due to the nearly every nanosecond changing complexity of things. :)
Such a thing existed 10 or 15 years ago. Unfortunately for the newbies, there are very few problems that newbies can attack, because if they were that simple, somebody would already have *done* them. One thing in particular that pretty much killed the kernel-janitors project (which did cleanup of code) was a change in the rules for kernel API changes. Before, somebody could add a new/changed API, and the janitors would change all the uses in the tree. We now require that a patch series that changes an API has to also fix all in-tree uses of the API.
On Tue, Aug 22, 2017 at 12:59:31PM -0400, valdis.kletnieks@vt.edu wrote:
On Tue, 22 Aug 2017 12:48:42 -0400, Cindy-Sue Causey said:
An observation that may just mean I haven't stumbled upon it yet is that it would be nice to... stumble upon... a list of kernel problems that *kernelnewbies* could cut their teeth on. I do understand that this is a naive wish list item due to the nearly every nanosecond changing complexity of things. :)
Such a thing existed 10 or 15 years ago. Unfortunately for the newbies, there are very few problems that newbies can attack, because if they were that simple, somebody would already have *done* them.
Not really, please look at drivers/staging/*/TODO there are loads of simple things left to do, with more being added all the time (a huge new wireless driver just landed that could use lots of cleanups.)
One thing in particular that pretty much killed the kernel-janitors project (which did cleanup of code) was a change in the rules for kernel API changes. Before, somebody could add a new/changed API, and the janitors would change all the uses in the tree. We now require that a patch series that changes an API has to also fix all in-tree uses of the API.
That's always been the rule, you could never break the build. What is better now in that people who do the new API usually fix everything up at the same time because they want to drop the old API sooner rather than later. thanks, greg k-h
Hi Greg, On Tue, Aug 22, 2017 at 11:09 PM, Greg KH <greg@kroah.com> wrote:
On Tue, Aug 22, 2017 at 12:59:31PM -0400, valdis.kletnieks@vt.edu wrote:
On Tue, 22 Aug 2017 12:48:42 -0400, Cindy-Sue Causey said:
An observation that may just mean I haven't stumbled upon it yet is that it would be nice to... stumble upon... a list of kernel problems that *kernelnewbies* could cut their teeth on. I do understand that this is a naive wish list item due to the nearly every nanosecond changing complexity of things. :)
Such a thing existed 10 or 15 years ago. Unfortunately for the newbies, there are very few problems that newbies can attack, because if they were that simple, somebody would already have *done* them.
Not really, please look at drivers/staging/*/TODO there are loads of simple things left to do, with more being added all the time (a huge new wireless driver just landed that could use lots of cleanups.)
Which wireless driver exactly? -Umair
On Wed, Aug 23, 2017 at 09:06:49PM +0530, Umair Khan wrote:
Hi Greg,
On Tue, Aug 22, 2017 at 11:09 PM, Greg KH <greg@kroah.com> wrote:
On Tue, Aug 22, 2017 at 12:59:31PM -0400, valdis.kletnieks@vt.edu wrote:
On Tue, 22 Aug 2017 12:48:42 -0400, Cindy-Sue Causey said:
An observation that may just mean I haven't stumbled upon it yet is that it would be nice to... stumble upon... a list of kernel problems that *kernelnewbies* could cut their teeth on. I do understand that this is a naive wish list item due to the nearly every nanosecond changing complexity of things. :)
Such a thing existed 10 or 15 years ago. Unfortunately for the newbies, there are very few problems that newbies can attack, because if they were that simple, somebody would already have *done* them.
Not really, please look at drivers/staging/*/TODO there are loads of simple things left to do, with more being added all the time (a huge new wireless driver just landed that could use lots of cleanups.)
Which wireless driver exactly?
The "new" one in the linux-next tree (it's also in the staging-next branch of the staging.git tree on git.kernel.org). Don't remember the exact name, it should be easy to find...
On Wed, Aug 23, 2017 at 03:57:05PM -0700, Greg KH wrote:
On Wed, Aug 23, 2017 at 09:06:49PM +0530, Umair Khan wrote:
Hi Greg,
On Tue, Aug 22, 2017 at 11:09 PM, Greg KH <greg@kroah.com> wrote:
On Tue, Aug 22, 2017 at 12:59:31PM -0400, valdis.kletnieks@vt.edu wrote:
On Tue, 22 Aug 2017 12:48:42 -0400, Cindy-Sue Causey said:
An observation that may just mean I haven't stumbled upon it yet is that it would be nice to... stumble upon... a list of kernel problems that *kernelnewbies* could cut their teeth on. I do understand that this is a naive wish list item due to the nearly every nanosecond changing complexity of things. :)
Such a thing existed 10 or 15 years ago. Unfortunately for the newbies, there are very few problems that newbies can attack, because if they were that simple, somebody would already have *done* them.
Not really, please look at drivers/staging/*/TODO there are loads of simple things left to do, with more being added all the time (a huge new wireless driver just landed that could use lots of cleanups.)
Which wireless driver exactly?
The "new" one in the linux-next tree (it's also in the staging-next branch of the staging.git tree on git.kernel.org). Don't remember the exact name, it should be easy to find...
looks like it may be drivers/staging/rtlwifi
On 08/22/2017 01:39 PM, Greg KH wrote:
On Tue, Aug 22, 2017 at 12:59:31PM -0400, valdis.kletnieks@vt.edu wrote:
On Tue, 22 Aug 2017 12:48:42 -0400, Cindy-Sue Causey said:
An observation that may just mean I haven't stumbled upon it yet is that it would be nice to... stumble upon... a list of kernel problems that *kernelnewbies* could cut their teeth on. I do understand that this is a naive wish list item due to the nearly every nanosecond changing complexity of things. :)
Such a thing existed 10 or 15 years ago. Unfortunately for the newbies, there are very few problems that newbies can attack, because if they were that simple, somebody would already have *done* them.
Not really, please look at drivers/staging/*/TODO there are loads of simple things left to do, with more being added all the time (a huge new wireless driver just landed that could use lots of cleanups.)
One thing in particular that pretty much killed the kernel-janitors project (which did cleanup of code) was a change in the rules for kernel API changes. Before, somebody could add a new/changed API, and the janitors would change all the uses in the tree. We now require that a patch series that changes an API has to also fix all in-tree uses of the API.
That's always been the rule, you could never break the build. What is better now in that people who do the new API usually fix everything up at the same time because they want to drop the old API sooner rather than later.
thanks,
greg k-h
You need the hardware though?
On Wed, Aug 23, 2017 at 04:08:16PM -0400, Ruben Safir wrote:
On 08/22/2017 01:39 PM, Greg KH wrote:
On Tue, Aug 22, 2017 at 12:59:31PM -0400, valdis.kletnieks@vt.edu wrote:
On Tue, 22 Aug 2017 12:48:42 -0400, Cindy-Sue Causey said:
An observation that may just mean I haven't stumbled upon it yet is that it would be nice to... stumble upon... a list of kernel problems that *kernelnewbies* could cut their teeth on. I do understand that this is a naive wish list item due to the nearly every nanosecond changing complexity of things. :)
Such a thing existed 10 or 15 years ago. Unfortunately for the newbies, there are very few problems that newbies can attack, because if they were that simple, somebody would already have *done* them.
Not really, please look at drivers/staging/*/TODO there are loads of simple things left to do, with more being added all the time (a huge new wireless driver just landed that could use lots of cleanups.)
One thing in particular that pretty much killed the kernel-janitors project (which did cleanup of code) was a change in the rules for kernel API changes. Before, somebody could add a new/changed API, and the janitors would change all the uses in the tree. We now require that a patch series that changes an API has to also fix all in-tree uses of the API.
That's always been the rule, you could never break the build. What is better now in that people who do the new API usually fix everything up at the same time because they want to drop the old API sooner rather than later.
thanks,
greg k-h
You need the hardware though?
Nope, not at all.
PS My apologies in advance if I initially flub things related to certain parts of emailing this list. Like starting with this email, I've culled some of the reply-to because I assume you all are already directly following this mailing list. :)
Don't do that culling. On the kernel related lists, Reply-all is the only acceptable protocol. There are 2 reasons: - With the huge volume of emails, it lets active participants in a thread use a email rule to pull those messages out into their own folder for priority review. - There are a bunch of kernel related mailing lists. I assume no one subscribes to them. But what happens if you want to ask a simple question on the SATA list and you're not subscribed? You don't have to subscribe, just send an email to the right address and all the participants in the thread will do a reply-all so you can see the responses without subscribing. Greg
On 08/22/2017 07:26 PM, Greg Freemyer wrote:
just send an email to the right address and all the participants in the thread will do a reply-all so you can see the responses without subscribing.??
-- So many immigrant groups have swept through our town that Brooklyn, like Atlantis, reaches mythological proportions in the mind of the world - RI Safir 1998 http://www.mrbrklyn.com DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002 http://www.nylxs.com - Leadership Development in Free Software http://www2.mrbrklyn.com/resources - Unpublished Archive http://www.coinhangout.com - coins! http://www.brooklyn-living.com Being so tracked is for FARM ANIMALS and and extermination camps, but incompatible with living as a free human being. -RI Safir 2013
Go through LDD3: https://lwn.net/Kernel/LDD3/ :) 2017-08-23 6:34 GMT-03:00 Ruben Safir <ruben@mrbrklyn.com>:
On 08/22/2017 07:26 PM, Greg Freemyer wrote:
just send an email to the right address and all the participants in the thread will do a reply-all so you can see the responses without subscribing.??
-- So many immigrant groups have swept through our town that Brooklyn, like Atlantis, reaches mythological proportions in the mind of the world - RI Safir 1998 http://www.mrbrklyn.com
DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002 http://www.nylxs.com - Leadership Development in Free Software http://www2.mrbrklyn.com/resources - Unpublished Archive http://www.coinhangout.com - coins! http://www.brooklyn-living.com
Being so tracked is for FARM ANIMALS and and extermination camps, but incompatible with living as a free human being. -RI Safir 2013
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
-- “If you're going to try, go all the way. Otherwise, don't even start. ..." Charles Bukowski
On Wed, Aug 23, 2017 at 5:34 AM, Ruben Safir <ruben@mrbrklyn.com> wrote:
On 08/22/2017 07:26 PM, Greg Freemyer wrote:
just send an email to the right address and all the participants in the thread will do a reply-all so you can see the responses without subscribing.??
Rubin, did you add the ?? If so, that's how it works. The linux-kernel mailing lists are not closed. Anyone can post an email to the list address, if it passes the spam filter it will get forwarded to the subscribers. The subscribers will do a reply-all and your thread is off to the races without you subscribing. Or let's say there is an ongoing thread on the SATA kernel mailing list and they need to bring in a core developer that isn't subscribed for some reason. They can just add him or her to the TO: line and going forward they should be kept in the loop for that thread. It's a nice model for managing a large number of specialists mailing lists. No one wants to subscribe to all of them, but from time to time people need to interact with the people on one of the specialist email lists and don't want to have to subscribe->participate->unsubscribe. Greg
On 08/23/2017 07:46 PM, Greg Freemyer wrote:
Rubin, did you add the ??
yes, somewhere it got reformated.
If so, that's how it works. The linux-kernel mailing lists are not closed. Anyone can post an email to the list address, if it passes the spam filter it will get forwarded to the subscribers.
The subscribers will do a reply-all and your thread is off to the races without you subscribing.
Or let's say there is an ongoing thread on the SATA kernel mailing list and they need to bring in a core developer that isn't subscribed for some reason.
They can just add him or her to the TO: line and going forward they should be kept in the loop for that thread.
Your not adding another list, your just adding a separate user. I usually add it to CC. What we do not do, normally, is allow a non-describer to post to a list, nor cross posting. That is chaos at best, and a relay hole for spam and worst.
It's a nice model for managing a large number of specialists mailing lists. No one wants to subscribe to all of them, but from time to time people need to interact with the people on one of the specialist email lists and don't want to have to subscribe->participate->unsubscribe.
Greg
-- So many immigrant groups have swept through our town that Brooklyn, like Atlantis, reaches mythological proportions in the mind of the world - RI Safir 1998 http://www.mrbrklyn.com DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002 http://www.nylxs.com - Leadership Development in Free Software http://www2.mrbrklyn.com/resources - Unpublished Archive http://www.coinhangout.com - coins! http://www.brooklyn-living.com Being so tracked is for FARM ANIMALS and and extermination camps, but incompatible with living as a free human being. -RI Safir 2013
What we do not do, normally, is allow a non-describer to post to a list,
I believe you're wrong, but I'm not sure I've ever tried. But on the XFS list as a primary example I believe I've seen a lot of non-subscribers posting and asking to be kept in copy of replies. Greg -- Greg Freemyer Advances are made by answering questions. Discoveries are made by questioning answers. — Bernard Haisch On Wed, Aug 23, 2017 at 8:03 PM, Ruben Safir <ruben@mrbrklyn.com> wrote:
On 08/23/2017 07:46 PM, Greg Freemyer wrote:
Rubin, did you add the ??
yes, somewhere it got reformated.
If so, that's how it works. The linux-kernel mailing lists are not closed. Anyone can post an email to the list address, if it passes the spam filter it will get forwarded to the subscribers.
The subscribers will do a reply-all and your thread is off to the races without you subscribing.
Or let's say there is an ongoing thread on the SATA kernel mailing list and they need to bring in a core developer that isn't subscribed for some reason.
They can just add him or her to the TO: line and going forward they should be kept in the loop for that thread.
Your not adding another list, your just adding a separate user. I usually add it to CC. What we do not do, normally, is allow a non-describer to post to a list, nor cross posting. That is chaos at best, and a relay hole for spam and worst.
It's a nice model for managing a large number of specialists mailing lists. No one wants to subscribe to all of them, but from time to time people need to interact with the people on one of the specialist email lists and don't want to have to subscribe->participate->unsubscribe.
Greg
-- So many immigrant groups have swept through our town that Brooklyn, like Atlantis, reaches mythological proportions in the mind of the world - RI Safir 1998 http://www.mrbrklyn.com
DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002 http://www.nylxs.com - Leadership Development in Free Software http://www2.mrbrklyn.com/resources - Unpublished Archive http://www.coinhangout.com - coins! http://www.brooklyn-living.com
Being so tracked is for FARM ANIMALS and and extermination camps, but incompatible with living as a free human being. -RI Safir 2013
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
On Wed, Aug 23, 2017 at 08:03:43PM -0400, Ruben Safir wrote:
They can just add him or her to the TO: line and going forward they should be kept in the loop for that thread.
Your not adding another list, your just adding a separate user. I usually add it to CC. What we do not do, normally, is allow a non-describer to post to a list, nor cross posting. That is chaos at best, and a relay hole for spam and worst.
Not true, that is how the kernel mailing lists at vger.kernel.org work, anyone can post to them, you do not have to be subscribed at all. The spam filtering on them is great, and really quite easy, just disallow html email and almost all of it goes away :) greg k-h
On 08/23/2017 08:46 PM, Greg KH wrote:
On Wed, Aug 23, 2017 at 08:03:43PM -0400, Ruben Safir wrote:
They can just add him or her to the TO: line and going forward they should be kept in the loop for that thread.
Your not adding another list, your just adding a separate user. I usually add it to CC. What we do not do, normally, is allow a non-describer to post to a list, nor cross posting. That is chaos at best, and a relay hole for spam and worst.
Not true, that is how the kernel mailing lists at vger.kernel.org work, anyone can post to them, you do not have to be subscribed at all.
The spam filtering on them is great, and really quite easy, just disallow html email and almost all of it goes away :)
I wish that was still true but it takes quite a bit more these days :(
greg k-h
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
-- So many immigrant groups have swept through our town that Brooklyn, like Atlantis, reaches mythological proportions in the mind of the world - RI Safir 1998 http://www.mrbrklyn.com DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002 http://www.nylxs.com - Leadership Development in Free Software http://www2.mrbrklyn.com/resources - Unpublished Archive http://www.coinhangout.com - coins! http://www.brooklyn-living.com Being so tracked is for FARM ANIMALS and and extermination camps, but incompatible with living as a free human being. -RI Safir 2013
On Tue, 22 Aug 2017 16:22:34 +0530, SUNIL KHORWAL said:
I'm new to linux kernel programming, I want to be a linux kernel hacker but i don't know where to start.
To repeat what I said previously on the subject: https://lists.kernelnewbies.org/pipermail/kernelnewbies/2017-April/017765.ht...
On Tue, Aug 22, 2017 at 04:22:34PM +0530, SUNIL KHORWAL wrote:
Hi, I'm new to linux kernel programming, I want to be a linux kernel hacker but i don't know where to start. Please help me.
I recently wrote some blog posts on this topic. You can check them out at http://tobin.cc/blog Greg is correct (as usual), there are loads of things to do in drivers/staging/* IMHO don't bother venturing far outside of staging for a while, and definitely don't submit cleanup patches to code outside of staging. You can safely get started learning kernel dev process patching staging/* Good luck, Tobin.
participants (10)
-
Cindy-Sue Causey -
Daniel. -
Greg Freemyer -
Greg KH -
Kamil Konieczny -
Ruben Safir -
SUNIL KHORWAL -
Tobin C. Harding -
Umair Khan -
valdis.kletnieks＠vt.edu