Hi list,
Whenever there is a change in the kernel API (or a new API is
introduced), all of the drivers that use the older API need to be
changed (or recommended to be changed). I believe it is the
responsibility of the person changing the kernel API, to change all
the drivers that have found their way into the kernel code?
How does this happen? Because the person who brought the change in the
API might not know the internals of all the drivers?
Is there any way volunteers like me can help in this exercise?
Thanks,
Dan
On Thu, Jan 18, 2007 at 09:45:04AM +0530, Daniel Rodrick wrote:
> Hi list,
>
> Whenever there is a change in the kernel API (or a new API is
> introduced), all of the drivers that use the older API need to be
> changed (or recommended to be changed). I believe it is the
> responsibility of the person changing the kernel API, to change all
> the drivers that have found their way into the kernel code?
Yes, that is the case.
> How does this happen? Because the person who brought the change in the
> API might not know the internals of all the drivers?
But they know why they made the change, so it's usually pretty obvious.
If not, they merely ask for help from the original author / maintainer
of the code, but that doesn't happen very often.
> Is there any way volunteers like me can help in this exercise?
Sure, go through the kernel building all of the different arches and all
of the modules and report what breaks due to api changes. The -mm tree
is the best place to test this stuff out, as that is where the changes
usually occur first.
good luck,
greg k-h
On Thu, Jan 18, 2007 at 09:45:04AM +0530, Daniel Rodrick wrote:
> Hi list,
>
> Whenever there is a change in the kernel API (or a new API is
> introduced), all of the drivers that use the older API need to be
> changed (or recommended to be changed). I believe it is the
> responsibility of the person changing the kernel API, to change all
> the drivers that have found their way into the kernel code?
>
> How does this happen? Because the person who brought the change in the
> API might not know the internals of all the drivers?
>
> Is there any way volunteers like me can help in this exercise?
See the /APIchanges in the Kernel Janitors TODO list
http://kernelnewbies.org/KernelJanitors/Todo
Also: Documentation/stable_api_nonsense.txt
--
Ahmed S. Darwish
http://darwish-07.blogspot.com
> >
> > Is there any way volunteers like me can help in this exercise?
>
> See the /APIchanges in the Kernel Janitors TODO list
> http://kernelnewbies.org/KernelJanitors/Todo
>
Hi,
This is regarding the link posted above.
1) How do I make sure if some one is NOT working on any of the
mentioned bullet points? Who coordinates? On what mailing list?
2) Do any patches for the above Todo list have the chances of getting
merged into the mainstream kernel? Who approves? I suppose the
respective maintainer of the driver / subsystem getting affected?
Thanks,
Rajat
"Rajat Jain" <[email protected]> writes:
>> >
>> > Is there any way volunteers like me can help in this exercise?
>>
>> See the /APIchanges in the Kernel Janitors TODO list
>> http://kernelnewbies.org/KernelJanitors/Todo
>>
>
> Hi,
>
> This is regarding the link posted above.
>
> 1) How do I make sure if some one is NOT working on any of the
> mentioned bullet points? Who coordinates? On what mailing list?
Depends on the issue. Release early and release often and there
won't be much duplicate work :)
> 2) Do any patches for the above Todo list have the chances of getting
> merged into the mainstream kernel? Who approves? I suppose the
> respective maintainer of the driver / subsystem getting affected?
Generally. Occasionally for small things other paths are available.
Eric
On Thu, Jan 18, 2007 at 11:05:53AM +0530, Rajat Jain wrote:
> >>
> >> Is there any way volunteers like me can help in this exercise?
> >
> >See the /APIchanges in the Kernel Janitors TODO list
> >http://kernelnewbies.org/KernelJanitors/Todo
> >
> [...]
> 1) How do I make sure if some one is NOT working on any of the
> mentioned bullet points? Who coordinates? On what mailing list?
Check latest trees to make sure the work is not duplicated. espicially
trees like -mm and subsystem ones.
> 2) Do any patches for the above Todo list have the chances of getting
> merged into the mainstream kernel? Who approves? I suppose the
> respective maintainer of the driver / subsystem getting affected?
I advise lurking (following/reading) the list for at least 2 or 3 weeks and
you'll automatically understand how the "system" works. Also check:
$KERNEL_TREE/Documentation/HOWTO
$KERNEL_TREE/Documentation/SubmittingPatches
$KERNEL_TREE/Documentation/CodingStyle
--
Ahmed S. Darwish
http://darwish-07.blogspot.com