Macros with unnecessary __constant prefix

This is another set of macros on which I worked during last 2 weeks. Use of __constant_ macros decreased after linux 3.10. According to one research of Julia lawall on deprecated functions, there were 56 uses of __constant_htons in linux 3.10, but now there are 9 only. Basically there is complete set of __constant_ macros in byte order [little endian and big endian] header files. I was in a impression that major part of kernel which was using these macros is handled . I was not expecting that much cases primarily. So,at first my aim was to send patches for all of those remaining cases and then at the end get rid of __constant_ definitions completely. But I was surprised when I ran Coccinelle semantic patch over linux-next. I got around 30 files which are still using these functions. Now it was important to figure out that these macros are not actually handled by anyone or there is something for which these macros are working really good.

Why __constant prefix is unnecessary??

There are two definitions for each __constant_ macro. That is one for big endian case and one for little endian case. Now for example consider macro cpu_to_le16. In big endian cases, macro cpu_to_le16 unfolds to __swab16 which provides special case for constants. In little endian cases, __constant_cpu_to_le16 and cpu_to_le16 expand directly to the same expression. So, we can replace __constant_cpu_to_le16 with cpu_to_le16. On the contrary, for big endian byte order macros opposite happens. For example in little endian cases, macro cpu_to_be16 unfolds to __swab16 which provides special case for constants and in big endian cases, __constant_cpu_to_be16 and cpu_to_be16 expand directly to the same expression. That’s why __constant prefix is unnecessary and we can completely get rid of these macros.

How Coccinelle semantic patch can help in replacing __constant_ with ?

This is very simple case for Coccinelle to handle. One just need 1 metavariable and 1 branch for each transformation in a semantic patch. Here, is a complete semantic patch with all __constant_   macros:

@@expression x;@@

(
– __constant_htons(x)
+ htons(x)
|
– __constant_htonl(x)
+ htonl(x)
|
– __constant_ntohs(x)
+ htons(x)
|
– __constant_ntohl(x)
+ htonl(x)
|
– __constant_cpu_to_le64(x)
+ cpu_to_le64(x)
|
– __constant_le64_to_cpu(x)
+ le64_to_cpu(x)
|
– __constant_cpu_to_le32(x)
+ cpu_to_le32(x)
|
– __constant_le32_to_cpu(x)
+ le32_to_cpu(x)
|
– __constant_cpu_to_le16(x)
+ cpu_to_le16(x)
|
– __constant_le16_to_cpu(x)
+ le16_to_cpu(x)
|
– __constant_cpu_to_be64(x)
+ cpu_to_be64(x)
|
– __constant_be64_to_cpu(x)
+ be64_to_cpu(x)
|
– __constant_cpu_to_be32(x)
+ cpu_to_be32(x)
|
– __constant_be32_to_cpu(x)
+ be32_to_cpu(x)
|
– __constant_cpu_to_be16(x)
+ cpu_to_be16(x)
|
– __constant_be16_to_cpu(x)
+ be16_to_cpu(x)
)

Does all files compiles after this change?

Yes. They do. Only problem was with s390 directory. Although errors which we get while compiling s390 files has nothing to do with this change. But those errors are in included header files and when header files have errors gcc eventually stops from there. So, to be sure that this change is correct, I checked each s390 file with cross compiler.

I have sent some patches related to same. I hope there is nothing which I am missing in this case. And once those patches will be accepted, I will send all other patches and hopefully till the end of internship I will be done with getting rid of all __constant_ definitions and their uses. Important thing which I learned during this was cross compilation of s390. I will write about cross compilation process of s390 in my next blog along with some other architecture related stuff.

Till then stay tuned! 🙂