Re: after effects of a kernel API change
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: after effects of a kernel API change
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: after effects of a kernel API change
"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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: after effects of a kernel API change
> > 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: after effects of a kernel API change
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: after effects of a kernel API change
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
after effects of a kernel API change
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
after effects of a kernel API change
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: after effects of a kernel API change
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: after effects of a kernel API change
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: after effects of a kernel API change
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: after effects of a kernel API change
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
