Don't know where to start linux kernel programming

[greg@kroah.com (Greg KH)]

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 at 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.