On Wed, Aug 23, 2017 at 04:08:16PM -0400, Ruben Safir wrote:

On 08/22/2017 01:39 PM, Greg KH wrote:

quoted

On Tue, Aug 22, 2017 at 12:59:31PM -0400, valdis.kletnieks at vt.edu wrote:

quoted

On Tue, 22 Aug 2017 12:48:42 -0400, Cindy-Sue Causey said:

quoted

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

quoted

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.