Kernel building with GCC plugins

Posted Jun 18, 2016 12:42 UTC (Sat) by PaXTeam (guest, #24616)
In reply to: Kernel building with GCC plugins by andresfreund
Parent article: Kernel building with GCC plugins

there never was 'a huge patchseries doing everything'. it started with individual patches per ops type (only a small subset of the types that could have been constified). the first fork on the road occured right there as some people ack'd some patches while others flat out refused to even accept the usefulness of ops constification. then some people requested a further breakup per subsystem *and* per ops type which as expected multiplied the number of patches. this is where the second fork occured where some people objected to *that*. there was never any consensus reached as to how exactly these constification patches should be submitted and IIRC, even those that got ack'ed didn't always get applied. the icing on the cake was that checkpatch did get modified to find a few more of the writable ops structures but as you can verify it yourself, not many took it seriously and the kernel continues to have such ops variables left writable that by policy should be const.

to post comments

Kernel building with GCC plugins

Posted Jun 19, 2016 18:05 UTC (Sun) by alonz (subscriber, #815) [Link] (1 responses)

I wonder if a half-way solution for constify would go better:

Have the plugin add a "const_instances" attribute, which when applied to a struct causes all instances of this struct to automatically become const. (Hopefully, this means the size of the patch to actually add this attribute to all ops structures would be much smaller than what Emese had to try and push through previously…)
Have another plugin (or an option to the same one) that produces warnings when a struct looks like it should be auto-const'able; make this shut up when the struct has a "non_const_instances" attribute (for ops structs that we do modify and cannot fix).

For initify—there is probably no other viable approach except the current one.

Another useful plugin would be something that causes errors on writes to ro_after_init variables from functions not marked __init… I wonder how feasible it is to implement.

Kernel building with GCC plugins

Posted Jun 19, 2016 19:26 UTC (Sun) by PaXTeam (guest, #24616) [Link]

the constify plugin already provides a do_const attribute for exactly that purpose (that we make use of for non-ops types already) and reporting on candidate types is also trivial to add in the constifiable() function. as for your last suggestion, it's doable but it will take a fair amount of static analysis that will effectively have to duplicate existing gcc logic in the C/C++ frontends. the easier way out is to mark these variables 'const' for a test compilation and examine the fallout.

Kernel building with GCC plugins

Posted Jun 21, 2016 19:40 UTC (Tue) by ebiederm (subscriber, #35028) [Link]

Changes that start with write a coccinelle script and update everything in the kernel. Always seem to be merged most easily if you have your own tree and send Linus the pull request. If the change is really as trivial as adding const where needed that shouldn't be a problem.

Now if a handful of those structures are not const for a some reason I can imaging problems. Otherwise it should be one of the boring things like big kernel lock push down, that just happens.

Kernel building with GCC plugins

Posted Jun 21, 2016 22:15 UTC (Tue) by tao (subscriber, #17563) [Link] (1 responses)

Having patches broken up per subsystem is *always* the norm for patch submission, especially for people who don't maintain any subsystems already. There are exceptions (people with a proven track record, such as Alexander Viro, for instance, can have their patches accepted even if they touch multiple subsystems at once), but unless a patch is of the "everything *has* to change in lockstep"
type, then you should expect having to submit a patch series per subsystem.

Sure, you might get lucky and have it accepted anyway, but if you get upset that your patch series doesn't accepted, without being willing to split it up by subsystem, then you might need to re-evaluate your notion that you're really doing what you can to get it merged.

Kernel building with GCC plugins

Posted Jun 21, 2016 23:37 UTC (Tue) by spender (guest, #23067) [Link]

Had you read any of the mailing list posts your exposition is based on, you would know that the "advice" you've provided is exactly what Emese ended up doing (as the PaX Team already explained in the comment you're replying to). I'll save you the hassle of using Google and provide you with direct links to the results of Emese breaking up the patches by subsystem and structure type. Feel free to read the rest of the thread.

Greg's request to have them split up by subsystem and structure type: http://marc.info/?l=linux-kernel&m=126020923129594&...
Responses to split up patches:
http://marc.info/?l=linux-kernel&m=126075717420046&...
http://marc.info/?l=linux-kernel&m=126075113315052&...
http://marc.info/?l=linux-kernel&m=126080632115907&...
http://marc.info/?l=linux-kernel&m=126009146214087&...

-Brad