TODO list

TODO list

[Kulikov Vasiliy]

Hi,

it seems that TODO list at http://kernelnewbies.org/KernelJanitors/Todo
is rather obsoleted, e.g. some tasks are already done. Is there any
renewed list?

Or I should mail to this mailing list with request to update concrete
task with proof that this task is done/etc.?

TODO List

[Benjamin BEURDOUCHE]

Hello everyone,
I am new to the mailing list and to the kernel and I was wondering if
there are some basics things I could do like fix warnings or else to avoid
to complex patches at firstŠ
There was http://kernelnewbies.org/KernelJanitors/Todo but it was last
edited 2009-04-20 14:59:47 by HenrikKretzschmar.

Any Ideas ? Thanks ! =)
Benjamin 



--
To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: TODO List

[Keith Woodie]

 I would be interested too.  I just joined last week.

 Thanks!
 Keith
>
> On Jul 8, 2012 9:38 AM, "Benjamin BEURDOUCHE" <dev@thecercle.org> wrote:
>>
>> Hello everyone,
>> I am new to the mailing list and to the kernel and I was wondering if
>> there are some basics things I could do like fix warnings or else to
>> avoid
>> to complex patches at firstÅ 
>> There was http://kernelnewbies.org/KernelJanitors/Todo but it was last
>> edited 2009-04-20 14:59:47 by HenrikKretzschmar.
>>
>> Any Ideas ? Thanks ! =)
>> Benjamin
>>
>>
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe
>> kernel-janitors" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

TODO list

[Ravi Kerur]

Team,

I am planning to take up following items from TODO list. If it's already picked please let me know. 

* pci_set_dma_mask() and friends should use DMA_BIT_MASK(nn) instead of

DMA_nnBIT_MASK or 0xffff... This is not 2.4 compatible, so beware of drivers with same code. [D: http://marc.theaimsgroup.com/?t\x108001993000001] Don't forget to #include dma-mapping.h

* check kmallocs for things like GFP_DMA without a memtype. 


Thanks,

Ravi

Re: TODO list

[Dan Carpenter]

On Fri, Apr 03, 2015 at 01:40:35PM -0700, Ravi Kerur wrote:
> Team,
> 
> I am planning to take up following items from TODO list. If it's already picked please let me know. 
> 
> * pci_set_dma_mask() and friends should use DMA_BIT_MASK(nn) instead of
> 
> DMA_nnBIT_MASK or 0xffff... This is not 2.4 compatible, so beware of drivers with same code. [D: http://marc.theaimsgroup.com/?t\x108001993000001] Don't forget to #include dma-mapping.h
> 
> * check kmallocs for things like GFP_DMA without a memtype. 
> 

The TODO is desperately out of date.  No one cares about 2.4 at all.
These days we don't really allow drivers to have backwards compatability
code so they compile on old kernels.  That stuff has to be stored out of
the main kernel tree.  We also have the compat-wireless and other
similar ways of backporting drivers.

There are still the occasional GFP_DMA without a memtype issue.  I'm not
certain what the fix is for those.  You could probably find them using
Coccinelle.

regards,
dan carpenter

Re: TODO list

[Ravi Kerur]

On 4/7/2015 12:49 AM, Dan Carpenter wrote:
> On Fri, Apr 03, 2015 at 01:40:35PM -0700, Ravi Kerur wrote:
>> Team,
>>
>> I am planning to take up following items from TODO list. If it's already picked please let me know. 
>>
>> * pci_set_dma_mask() and friends should use DMA_BIT_MASK(nn) instead of
>>
>> DMA_nnBIT_MASK or 0xffff... This is not 2.4 compatible, so beware of drivers with same code. [D: http://marc.theaimsgroup.com/?t\x108001993000001] Don't forget to #include dma-mapping.h
>>
>> * check kmallocs for things like GFP_DMA without a memtype. 
>>
> 
> The TODO is desperately out of date.  No one cares about 2.4 at all.
> These days we don't really allow drivers to have backwards compatability
> code so they compile on old kernels.  That stuff has to be stored out of
> the main kernel tree.  We also have the compat-wireless and other
> similar ways of backporting drivers.

Thanks Dan. Do you recommend anything else for contribution? I am not a
newbie to kernel but never contributed to kernel before so any inputs
appreciated.

Thanks,
Ravi
> 
> There are still the occasional GFP_DMA without a memtype issue.  I'm not
> certain what the fix is for those.  You could probably find them using
> Coccinelle.
> 
> regards,
> dan carpenter
> 

Re: TODO list

[Dan Carpenter]

On Wed, Apr 08, 2015 at 05:36:01PM -0700, Ravi Kerur wrote:
> 
> 
> On 4/7/2015 12:49 AM, Dan Carpenter wrote:
> > On Fri, Apr 03, 2015 at 01:40:35PM -0700, Ravi Kerur wrote:
> >> Team,
> >>
> >> I am planning to take up following items from TODO list. If it's already picked please let me know. 
> >>
> >> * pci_set_dma_mask() and friends should use DMA_BIT_MASK(nn) instead of
> >>
> >> DMA_nnBIT_MASK or 0xffff... This is not 2.4 compatible, so beware of drivers with same code. [D: http://marc.theaimsgroup.com/?t\x108001993000001] Don't forget to #include dma-mapping.h
> >>
> >> * check kmallocs for things like GFP_DMA without a memtype. 
> >>
> > 
> > The TODO is desperately out of date.  No one cares about 2.4 at all.
> > These days we don't really allow drivers to have backwards compatability
> > code so they compile on old kernels.  That stuff has to be stored out of
> > the main kernel tree.  We also have the compat-wireless and other
> > similar ways of backporting drivers.
> 
> Thanks Dan. Do you recommend anything else for contribution? I am not a
> newbie to kernel but never contributed to kernel before so any inputs
> appreciated.

There is always stuff to fix in staging.  It's at all levels of
difficulty.

regards,
dan carpenter

Re: TODO list

[Ravi Kerur]

On 4/9/2015 1:48 AM, Dan Carpenter wrote:
> On Wed, Apr 08, 2015 at 05:36:01PM -0700, Ravi Kerur wrote:
>>
>>
>> On 4/7/2015 12:49 AM, Dan Carpenter wrote:
>>> On Fri, Apr 03, 2015 at 01:40:35PM -0700, Ravi Kerur wrote:
>>>> Team,
>>>>
>>>> I am planning to take up following items from TODO list. If it's already picked please let me know. 
>>>>
>>>> * pci_set_dma_mask() and friends should use DMA_BIT_MASK(nn) instead of
>>>>
>>>> DMA_nnBIT_MASK or 0xffff... This is not 2.4 compatible, so beware of drivers with same code. [D: http://marc.theaimsgroup.com/?t\x108001993000001] Don't forget to #include dma-mapping.h
>>>>
>>>> * check kmallocs for things like GFP_DMA without a memtype. 
>>>>
>>>
>>> The TODO is desperately out of date.  No one cares about 2.4 at all.
>>> These days we don't really allow drivers to have backwards compatability
>>> code so they compile on old kernels.  That stuff has to be stored out of
>>> the main kernel tree.  We also have the compat-wireless and other
>>> similar ways of backporting drivers.
>>
>> Thanks Dan. Do you recommend anything else for contribution? I am not a
>> newbie to kernel but never contributed to kernel before so any inputs
>> appreciated.
> 
> There is always stuff to fix in staging.  It's at all levels of
> difficulty.

Can you please point me to the link or anything which lists what needs to be done. I can pick some of it.

Thanks,
Ravi

> 
> regards,
> dan carpenter
> 

Re: TODO list

[Julia Lawall]

On Thu, 9 Apr 2015, Ravi Kerur wrote:

> 
> 
> On 4/9/2015 1:48 AM, Dan Carpenter wrote:
> > On Wed, Apr 08, 2015 at 05:36:01PM -0700, Ravi Kerur wrote:
> >>
> >>
> >> On 4/7/2015 12:49 AM, Dan Carpenter wrote:
> >>> On Fri, Apr 03, 2015 at 01:40:35PM -0700, Ravi Kerur wrote:
> >>>> Team,
> >>>>
> >>>> I am planning to take up following items from TODO list. If it's already picked please let me know. 
> >>>>
> >>>> * pci_set_dma_mask() and friends should use DMA_BIT_MASK(nn) instead of
> >>>>
> >>>> DMA_nnBIT_MASK or 0xffff... This is not 2.4 compatible, so beware of drivers with same code. [D: http://marc.theaimsgroup.com/?t\x108001993000001] Don't forget to #include dma-mapping.h
> >>>>
> >>>> * check kmallocs for things like GFP_DMA without a memtype. 
> >>>>
> >>>
> >>> The TODO is desperately out of date.  No one cares about 2.4 at all.
> >>> These days we don't really allow drivers to have backwards compatability
> >>> code so they compile on old kernels.  That stuff has to be stored out of
> >>> the main kernel tree.  We also have the compat-wireless and other
> >>> similar ways of backporting drivers.
> >>
> >> Thanks Dan. Do you recommend anything else for contribution? I am not a
> >> newbie to kernel but never contributed to kernel before so any inputs
> >> appreciated.
> > 
> > There is always stuff to fix in staging.  It's at all levels of
> > difficulty.
> 
> Can you please point me to the link or anything which lists what needs to be done. I can pick some of it.

You can run checkpatch, or other tools and fix the things that they 
highlight.  Once you start really looking at the code, you are likely to 
see other things that can be improved as well.  Some staging drivers also 
have TODO lists.

julia

Re: TODO list

[Ravi Kerur]

On 4/9/2015 10:34 PM, Julia Lawall wrote:
> 
> 
> On Thu, 9 Apr 2015, Ravi Kerur wrote:
> 
>>
>>
>> On 4/9/2015 1:48 AM, Dan Carpenter wrote:
>>> On Wed, Apr 08, 2015 at 05:36:01PM -0700, Ravi Kerur wrote:
>>>>
>>>>
>>>> On 4/7/2015 12:49 AM, Dan Carpenter wrote:
>>>>> On Fri, Apr 03, 2015 at 01:40:35PM -0700, Ravi Kerur wrote:
>>>>>> Team,
>>>>>>
>>>>>> I am planning to take up following items from TODO list. If it's already picked please let me know. 
>>>>>>
>>>>>> * pci_set_dma_mask() and friends should use DMA_BIT_MASK(nn) instead of
>>>>>>
>>>>>> DMA_nnBIT_MASK or 0xffff... This is not 2.4 compatible, so beware of drivers with same code. [D: http://marc.theaimsgroup.com/?t\x108001993000001] Don't forget to #include dma-mapping.h
>>>>>>
>>>>>> * check kmallocs for things like GFP_DMA without a memtype. 
>>>>>>
>>>>>
>>>>> The TODO is desperately out of date.  No one cares about 2.4 at all.
>>>>> These days we don't really allow drivers to have backwards compatability
>>>>> code so they compile on old kernels.  That stuff has to be stored out of
>>>>> the main kernel tree.  We also have the compat-wireless and other
>>>>> similar ways of backporting drivers.
>>>>
>>>> Thanks Dan. Do you recommend anything else for contribution? I am not a
>>>> newbie to kernel but never contributed to kernel before so any inputs
>>>> appreciated.
>>>
>>> There is always stuff to fix in staging.  It's at all levels of
>>> difficulty.
>>
>> Can you please point me to the link or anything which lists what needs to be done. I can pick some of it.
> 
> You can run checkpatch, or other tools and fix the things that they 
> highlight.  Once you start really looking at the code, you are likely to 
> see other things that can be improved as well.  Some staging drivers also 
> have TODO lists.
> 

My question was which subsystem or specific area to start? Should I pick some random subsystem of my interest and start working on it? 

-Ravi
 
> julia
> 

Re: TODO list

[Julia Lawall]

On Fri, 10 Apr 2015, Ravi Kerur wrote:

> 
> 
> On 4/9/2015 10:34 PM, Julia Lawall wrote:
> > 
> > 
> > On Thu, 9 Apr 2015, Ravi Kerur wrote:
> > 
> >>
> >>
> >> On 4/9/2015 1:48 AM, Dan Carpenter wrote:
> >>> On Wed, Apr 08, 2015 at 05:36:01PM -0700, Ravi Kerur wrote:
> >>>>
> >>>>
> >>>> On 4/7/2015 12:49 AM, Dan Carpenter wrote:
> >>>>> On Fri, Apr 03, 2015 at 01:40:35PM -0700, Ravi Kerur wrote:
> >>>>>> Team,
> >>>>>>
> >>>>>> I am planning to take up following items from TODO list. If it's already picked please let me know. 
> >>>>>>
> >>>>>> * pci_set_dma_mask() and friends should use DMA_BIT_MASK(nn) instead of
> >>>>>>
> >>>>>> DMA_nnBIT_MASK or 0xffff... This is not 2.4 compatible, so beware of drivers with same code. [D: http://marc.theaimsgroup.com/?t\x108001993000001] Don't forget to #include dma-mapping.h
> >>>>>>
> >>>>>> * check kmallocs for things like GFP_DMA without a memtype. 
> >>>>>>
> >>>>>
> >>>>> The TODO is desperately out of date.  No one cares about 2.4 at all.
> >>>>> These days we don't really allow drivers to have backwards compatability
> >>>>> code so they compile on old kernels.  That stuff has to be stored out of
> >>>>> the main kernel tree.  We also have the compat-wireless and other
> >>>>> similar ways of backporting drivers.
> >>>>
> >>>> Thanks Dan. Do you recommend anything else for contribution? I am not a
> >>>> newbie to kernel but never contributed to kernel before so any inputs
> >>>> appreciated.
> >>>
> >>> There is always stuff to fix in staging.  It's at all levels of
> >>> difficulty.
> >>
> >> Can you please point me to the link or anything which lists what needs to be done. I can pick some of it.
> > 
> > You can run checkpatch, or other tools and fix the things that they 
> > highlight.  Once you start really looking at the code, you are likely to 
> > see other things that can be improved as well.  Some staging drivers also 
> > have TODO lists.
> > 
> 
> My question was which subsystem or specific area to start? Should I pick some random subsystem of my interest and start working on it? 

Dan suggested staging.  In terms of learning, it doesn't matter what you 
choose to get started.  You should avoid the following drivers, though, as 
they are on the way out of the kernel:

i2o
line6
media/parport
media/tlg2300
media/vino

julia

Re: TODO list

[Dan Carpenter]

On Mon, Apr 13, 2015 at 02:46:53PM -0700, Ravi Kerur wrote:
> Team,
> 
> I will take up net/sched files and get a clean checkpatch run on them. I am working on a project which involves this piece of code and as part of learning the code I can clean-up the files. I ran checkpatch on some of them and I do see that it needs cleaning. For e.g.
> 
> #:~/git/kernels/staging$ perl scripts/checkpatch.pl -f net/sched/act_api.c
> WARNING: networking block comments don't use an empty /* line, use /* Comment...
> #41: FILE: net/sched/act_api.c:41:
> +	/*
> +	 * gen_estimator est_timer() might access p->tcfc_locki
> 
> CHECK: Comparison to NULL could be written "!nest"
> #95: FILE: net/sched/act_api.c:95:
> +			if (nest = NULL)
> ...
> [...]

No one cares about either of those things.  If it's a drivers/staging
patch then we would merge it, but if it's a patch to net/sched/act_api.c
they will probably just get annoyed with you.

regards,
dan carpenter

Re: TODO list

[Ravi Kerur]

On 4/13/2015 3:02 PM, Dan Carpenter wrote:
> On Mon, Apr 13, 2015 at 02:46:53PM -0700, Ravi Kerur wrote:
>> Team,
>>
>> I will take up net/sched files and get a clean checkpatch run on them. I am working on a project which involves this piece of code and as part of learning the code I can clean-up the files. I ran checkpatch on some of them and I do see that it needs cleaning. For e.g.
>>
>> #:~/git/kernels/staging$ perl scripts/checkpatch.pl -f net/sched/act_api.c
>> WARNING: networking block comments don't use an empty /* line, use /* Comment...
>> #41: FILE: net/sched/act_api.c:41:
>> +	/*
>> +	 * gen_estimator est_timer() might access p->tcfc_locki
>>
>> CHECK: Comparison to NULL could be written "!nest"
>> #95: FILE: net/sched/act_api.c:95:
>> +			if (nest = NULL)
>> ...
>> [...]
> 
> No one cares about either of those things.  If it's a drivers/staging
> patch then we would merge it, but if it's a patch to net/sched/act_api.c
> they will probably just get annoyed with you.
> 

Thanks, The reason I didn't pick from drivers/staging is that I don't have necessary hardware to test the changes. Hence I chose something which can be tested without any restriction and get it done. Do you have any recommendations?

Thanks,
Ravi

> regards,
> dan carpenter
> 

Re: TODO list

[Dan Carpenter]

On Mon, Apr 13, 2015 at 03:42:38PM -0700, Ravi Kerur wrote:
> Thanks, The reason I didn't pick from drivers/staging is that I don't
> have necessary hardware to test the changes. Hence I chose something
> which can be tested without any restriction and get it done. Do you
> have any recommendations?

Most people send their staging patches without testing, honestly.

Otherwise just restrict yourself to drivers/.

Also checkpatch on its own is not really a justification for sending
patches outside of staging/.  The patch has to make the code better for
humans.

regards,
dan carpenter