Re: [Cocci] semantic patch feasibility
Besides moving the function pointers assigned to the structure gpio_chip fields to the new struct gpio_chip_ops, a pointer to the new struct gpio_chip_ops has to be assigned to the struct gpio_chip .ops field. Will any macros become relevant for such a source code reorganisation? So where to put the new structure is constrained by where struct gpio_chip fields are set. If is easier we can define to be just before the function where the assignments were made but I don't know if it can be generalized. I am curious how a generalisation should be described here. But I don't want to waste your time since I still didn't have time to get familiar with cocinelle/spatch syntax to get into the details. I find that the understanding of this syntax is a secondary issue. Is it more important to clarify the basic change process before? Do you need to consider any variations for the initialisation of the affected data structure? Is the specification precise enough so that such an algorithm can be added to a kind of pattern collection? http://refactoring.com/catalog/extractInterface.html http://c2.com/cgi/wiki?ExtractInterface Regards, Markus ___ Cocci mailing list Cocci@systeme.lip6.fr https://systeme.lip6.fr/mailman/listinfo/cocci
Re: [Cocci] semantic patch feasibility
On Fri, 25 Apr 2014, Javier Martinez Canillas wrote: Hello, I'm a Linux kernel developer doing a big refactoring on the GPIO subsytem. I was wondering if the change I'm doing manually could be automated by using cocinelle but I've no experience neither writing semantic patches nor the SmPL language grammar. It looks quite possible. In looking at the code, though, I wasn't sure what is your strategy for where to place the new structure definition, in the case where there was no structure before. Would it be OK to put it next to the probe function? julia ___ Cocci mailing list Cocci@systeme.lip6.fr https://systeme.lip6.fr/mailman/listinfo/cocci
Re: [Cocci] semantic patch feasibility
On Fri, 25 Apr 2014, SF Markus Elfring wrote: The attached patch illustrated a number of them. How do you see the chances for generalisation of this concrete example? I think it should be quite straightforward. One either takes the assignments out of the function and puts them into a structure initializer, or if there is a structure initializer already, one cuts it up into what is wanted for each of the separate functions. Maybe creating the name of the new structure is an issue? I didn't look carefully enough to see if there was a pattern. julia ___ Cocci mailing list Cocci@systeme.lip6.fr https://systeme.lip6.fr/mailman/listinfo/cocci
Re: [Cocci] semantic patch feasibility
I'm doing a kernel wide change on a core API used by a lot of drivers (~250) so is a lot of work to do this manually and I can miss a driver when grepping the code. How do you identify your update candidates? Have you got any specific filter pattern in mind already? Your task will become more interesting if you are going to specify the precise query on affected source files, won't it? Regards, Markus ___ Cocci mailing list Cocci@systeme.lip6.fr https://systeme.lip6.fr/mailman/listinfo/cocci
Re: [Cocci] semantic patch feasibility
On Fri, Apr 25, 2014 at 6:24 PM, Julia Lawall julia.law...@lip6.fr wrote: On Fri, 25 Apr 2014, SF Markus Elfring wrote: I was wondering if the change I'm doing manually could be automated by using cocinelle but I've no experience neither writing semantic patches nor the SmPL language grammar. I would like to point out a general consideration. Semantic patches can be developed for some use cases. I find that corresponding efforts are only useful if such a generalised patch can be applied to a source code base several times. I doubt that you want to try it out for a single source code adjustment. It might be that a need will appear to perform a transformation once more a bit later, doesn't it? I believe that he has hundreds of use cases. The attached patch illustrated a number of them. julia Exactly, there are much more drivers than the ones I already modified in the attached patched. It was just to give you an example of the level of complexity (or not) of the change I'm doing. Best regards, Javier ___ Cocci mailing list Cocci@systeme.lip6.fr https://systeme.lip6.fr/mailman/listinfo/cocci
Re: [Cocci] semantic patch feasibility
Hello Markus, On Fri, Apr 25, 2014 at 4:30 PM, SF Markus Elfring elfr...@users.sourceforge.net wrote: I was wondering if the change I'm doing manually could be automated by using cocinelle but I've no experience neither writing semantic patches nor the SmPL language grammar. I would like to point out a general consideration. Semantic patches can be developed for some use cases. I find that corresponding efforts are only useful if such a generalised patch can be applied to a source code base several times. I doubt that you want to try it out for a single source code adjustment. It might be that a need will appear to perform a transformation once more a bit later, doesn't it? Thanks a lot for your feedback. I understand the the primary use for cocinelle could be to have generalized patches that can detect common semantic errors to have a flexible and extensible static analysis. In this case I'm interested in a different use case though. I'm doing a kernel wide change on a core API used by a lot of drivers (~250) so is a lot of work to do this manually and I can miss a driver when grepping the code. And even if I manage to do all the manual changes (I've already changed a bunch of them), I don't have cross-compiler to at least build test the drivers for every single architecture to find out if I made a silly programming mistake. So I think that it is much safer to express the change as a semantic patch even if the change is going to be made only once, in order to avoid introducing any build regressions. Best regards, Javier ___ Cocci mailing list Cocci@systeme.lip6.fr https://systeme.lip6.fr/mailman/listinfo/cocci
Re: [Cocci] semantic patch feasibility
Hello Julia, On Fri, Apr 25, 2014 at 8:03 PM, Julia Lawall julia.law...@lip6.fr wrote: On Fri, 25 Apr 2014, SF Markus Elfring wrote: The attached patch illustrated a number of them. How do you see the chances for generalisation of this concrete example? I think it should be quite straightforward. One either takes the assignments out of the function and puts them into a structure initializer, or if there is a structure initializer already, one cuts it up into what is wanted for each of the separate functions. Maybe creating the name of the new structure is an issue? I didn't look carefully enough to see if there was a pattern. julia I'm glad to know that should be straightforward. To name the new structure I've been trying to deduce the naming scheme that the original driver author used to name the GPIO operations and following that convention. But if for the sake of simplicity we use a standard name that will be used on all drivers, that's ok too. After all the structures are static and later drivers maintainers can rename the structure if they want a more suitable name. Thanks a lot to Markus and you for the feedback. Now that I know that is possible, I'll study the SmPL grammar, look at the examples and ask silly questions here if I find issues :-) Best regards, Javier ___ Cocci mailing list Cocci@systeme.lip6.fr https://systeme.lip6.fr/mailman/listinfo/cocci
Re: [Cocci] semantic patch feasibility
Hello Julia, On Fri, Apr 25, 2014 at 6:23 PM, Julia Lawall julia.law...@lip6.fr wrote: On Fri, 25 Apr 2014, Javier Martinez Canillas wrote: Hello, I'm a Linux kernel developer doing a big refactoring on the GPIO subsytem. I was wondering if the change I'm doing manually could be automated by using cocinelle but I've no experience neither writing semantic patches nor the SmPL language grammar. It looks quite possible. In looking at the code, though, I wasn't sure what is your strategy for where to place the new structure definition, in the case where there was no structure before. Would it be OK to put it next to the probe function? julia Thanks a lot for taking the time to look at this! I've been adding the new structure definition right after all the functions have been defined since that is a common pattern found in other kernel subsystems. But since this is a cleanup and if is going to be easier to define the semantic patch by placing the structure before the probe function then that works for me too and later drivers maintainers can send incremental patches to change wherever they find more suitable. Best regards, Javier ___ Cocci mailing list Cocci@systeme.lip6.fr https://systeme.lip6.fr/mailman/listinfo/cocci
Re: [Cocci] semantic patch feasibility
On Fri, 25 Apr 2014, Javier Martinez Canillas wrote: Hello Julia, On Fri, Apr 25, 2014 at 6:23 PM, Julia Lawall julia.law...@lip6.fr wrote: On Fri, 25 Apr 2014, Javier Martinez Canillas wrote: Hello, I'm a Linux kernel developer doing a big refactoring on the GPIO subsytem. I was wondering if the change I'm doing manually could be automated by using cocinelle but I've no experience neither writing semantic patches nor the SmPL language grammar. It looks quite possible. In looking at the code, though, I wasn't sure what is your strategy for where to place the new structure definition, in the case where there was no structure before. Would it be OK to put it next to the probe function? julia Thanks a lot for taking the time to look at this! I've been adding the new structure definition right after all the functions have been defined since that is a common pattern found in other kernel subsystems. But since this is a cleanup and if is going to be easier to define the semantic patch by placing the structure before the probe function then that works for me too and later drivers maintainers can send incremental patches to change wherever they find more suitable. Well, you could also put it after the probe function. You could also find the ending position of all of the functions and put it after the last one, but that could be a bit complicated. julia ___ Cocci mailing list Cocci@systeme.lip6.fr https://systeme.lip6.fr/mailman/listinfo/cocci
Re: [Cocci] semantic patch feasibility
On Fri, 25 Apr 2014, Javier Martinez Canillas wrote: Hello Julia, On Fri, Apr 25, 2014 at 8:03 PM, Julia Lawall julia.law...@lip6.fr wrote: On Fri, 25 Apr 2014, SF Markus Elfring wrote: The attached patch illustrated a number of them. How do you see the chances for generalisation of this concrete example? I think it should be quite straightforward. One either takes the assignments out of the function and puts them into a structure initializer, or if there is a structure initializer already, one cuts it up into what is wanted for each of the separate functions. Maybe creating the name of the new structure is an issue? I didn't look carefully enough to see if there was a pattern. julia I'm glad to know that should be straightforward. To name the new structure I've been trying to deduce the naming scheme that the original driver author used to name the GPIO operations and following that convention. But if for the sake of simplicity we use a standard name that will be used on all drivers, that's ok too. After all the structures are static and later drivers maintainers can rename the structure if they want a more suitable name. I thought you could look for the get or set field, see what it is assigned to, and make a new name from that one. For maximum flexibility, you can make new names in ocaml or python code. You can see how to do this in the file demos/pythontococci.cocci. julia ___ Cocci mailing list Cocci@systeme.lip6.fr https://systeme.lip6.fr/mailman/listinfo/cocci
Re: [Cocci] semantic patch feasibility
On Fri, 25 Apr 2014, Javier Martinez Canillas wrote: Hello Markus, On Fri, Apr 25, 2014 at 4:30 PM, SF Markus Elfring elfr...@users.sourceforge.net wrote: I was wondering if the change I'm doing manually could be automated by using cocinelle but I've no experience neither writing semantic patches nor the SmPL language grammar. I would like to point out a general consideration. Semantic patches can be developed for some use cases. I find that corresponding efforts are only useful if such a generalised patch can be applied to a source code base several times. I doubt that you want to try it out for a single source code adjustment. It might be that a need will appear to perform a transformation once more a bit later, doesn't it? Thanks a lot for your feedback. I understand the the primary use for cocinelle could be to have generalized patches that can detect common semantic errors to have a flexible and extensible static analysis. Making this kind of frequent change is a perfectly reasonable, indeed intended, use of Coccinelle. julia In this case I'm interested in a different use case though. I'm doing a kernel wide change on a core API used by a lot of drivers (~250) so is a lot of work to do this manually and I can miss a driver when grepping the code. And even if I manage to do all the manual changes (I've already changed a bunch of them), I don't have cross-compiler to at least build test the drivers for every single architecture to find out if I made a silly programming mistake. So I think that it is much safer to express the change as a semantic patch even if the change is going to be made only once, in order to avoid introducing any build regressions. Best regards, Javier ___ Cocci mailing list Cocci@systeme.lip6.fr https://systeme.lip6.fr/mailman/listinfo/cocci ___ Cocci mailing list Cocci@systeme.lip6.fr https://systeme.lip6.fr/mailman/listinfo/cocci
Re: [Cocci] semantic patch feasibility
Hello Julia, On Fri, Apr 25, 2014 at 11:25 PM, Julia Lawall julia.law...@lip6.fr wrote: On Fri, 25 Apr 2014, Javier Martinez Canillas wrote: Hello Julia, On Fri, Apr 25, 2014 at 6:23 PM, Julia Lawall julia.law...@lip6.fr wrote: On Fri, 25 Apr 2014, Javier Martinez Canillas wrote: Hello, I'm a Linux kernel developer doing a big refactoring on the GPIO subsytem. I was wondering if the change I'm doing manually could be automated by using cocinelle but I've no experience neither writing semantic patches nor the SmPL language grammar. It looks quite possible. In looking at the code, though, I wasn't sure what is your strategy for where to place the new structure definition, in the case where there was no structure before. Would it be OK to put it next to the probe function? julia Thanks a lot for taking the time to look at this! I've been adding the new structure definition right after all the functions have been defined since that is a common pattern found in other kernel subsystems. But since this is a cleanup and if is going to be easier to define the semantic patch by placing the structure before the probe function then that works for me too and later drivers maintainers can send incremental patches to change wherever they find more suitable. Well, you could also put it after the probe function. You could also find the ending position of all of the functions and put it after the last one, but that could be a bit complicated. Besides moving the function pointers assigned to the structure gpio_chip fields to the new struct gpio_chip_ops, a pointer to the new struct gpio_chip_ops has to be assigned to the struct gpio_chip .ops field. So where to put the new structure is constrained by where struct gpio_chip fields are set. If is easier we can define to be just before the function where the assignments were made but I don't know if it can be generalized. But I don't want to waste your time since I still didn't have time to get familiar with cocinelle/spatch syntax to get into the details. I'll figure out and let you know if I have any issues. Thanks a lot and best regards, Javier ___ Cocci mailing list Cocci@systeme.lip6.fr https://systeme.lip6.fr/mailman/listinfo/cocci
