| |||||||||||||
Better kernels with GCC pluginsBetter kernels with GCC pluginsPosted Oct 16, 2011 19:14 UTC (Sun) by vonbrand (subscriber, #4458)In reply to: Better kernels with GCC plugins by PaXTeam Parent article: Better kernels with GCC plugins
The OP's point, which is that semantics differing markedly from ordinary C make code less readable, is perfectly valid.which is what i called FUD. the only semantical change we can talk about in this context is the forced constification of certain types and variables, the exact details of which i described above (did you read them?) and can also be learned from the source code of the constify plugin. this change in semantics, surprise surprise, does not make *any* change to the kernel source code, therefore it is as readable as it is without using the plugin. There is a semantics change, and you say yourself you have to check regularly if any of the assumptions of your behind-the-secenes changes get violated and fix the plugin accordingly. See, that is exactly the kinds of changes that the random kernel hacker won't be able to do by herself (and she will probably left scratching her head when perfectly sane looking C doesn't compile, or Oopses inexplicably, or changes plainly stated in the source just don't work). The cost for you is probably much larger than for everybody else, but that doesn't mean that the cost for others doesn't exist. As also stated, this extends the source of the kernel from GCC-C to PaX-C + GCC-plugins, and that means there have to be people familiar enough with that combination to keep it running (What has been called "the bus test": What happens to the kernel if you get run over by a bus?). A cost/benefit analysis would say that the benefit is slim to none (if there was a huge benefit, the changes would presumably have been done or accepted by the regular kernel hackers; please do spare me your conspiracy theories); costs include a specially spiked compiler (every time a risk) plus the growingly complex and opaque PaX-C language and GCC plugins as source, run-of-the-mill competent C programming skills aren't enough to pick up kernel hacking anymore. Sounds like a net loss today, and getting worse as time passes. And at least for constification there are perfectly sane solutions using vanilla C, so there is no real need for this circuitous route, so there isn't much of a justification either.
(Log in to post comments)
Better kernels with GCC plugins Posted Oct 17, 2011 21:45 UTC (Mon) by PaXTeam (subscriber, #24616) [Link]
> There is a semantics change, and you say yourself you have to check
> regularly if any of the assumptions of your behind-the-secenes changes > get violated and fix the plugin accordingly.
actually no, we don't have to fix the plugin, we have to 'fix' the kernel source rather. we made a conscious design decision to not bury non-constifiable type/variable names in the plugin code and implemented two attributes to give explicit control instead (with the default being 'constify unless marked' in PaX, but it's easy to flip it around to become 'constify if marked').
> See, that is exactly the kinds of changes that the random kernel hacker
you mean, upon seeing a clear compiler error about assigning to a read-only variable one won't be able to add a simple __no_const attribute to the affected type? this is the same effort when one has to remove a const qualifier for the same error message or to add annotations for sparse, etc. it's not a particularly hard to learn skill, maybe you want to give it a try just to see it for yourself instead of taking my word for it?
> and she will probably left scratching her head when perfectly sane
the compiler error message is very clear about what goes wrong ;), i never had a problem with figuring out what to 'fix', this gcc behaviour induced by the plugin was a conscious choice actually so that we can let the compiler's existing infrastructure figure out where the 'bad' code is (actually, the quotes are not exactly justified, it did find bad code).
> or Oopses inexplicably,
we're getting into FUD territory. how would the constify plugin cause an oops?
> or changes plainly stated in the source just don't work
what do you mean here?
> The cost for you is probably much larger than for everybody else [...]
yes, it's an insane amount of time. 15 mins of compiling an allyesconfig/allmodconfig kernel and say another hour to filter out and fix the newly introduced problems. every 3 months. i wish all other kernel changes cost this much to fix/work around ;). and if the plugin was part of the normal development process then this cost would be a minute per problem per developer (which is seemingly an order of magnitude more effort than people invest into running and acting on checkpatch). and if the default behaviour were flipped, it'd be back to the kernel janitor folks to add do_const every now and then to the deserving types.
> As also stated, this extends the source of the kernel from GCC-C to
if only there was such a thing as GCC-C ;). but there isn't, the kernel isn't written to any particular C standard, not even any GNU C specific extension or implementation (ever tried -O0?), it's some mix of these.
constifying ops structures is janitorial work, it's something that a programmer should have done ("if you don't mean this variable to be actually writable then don't leave it writable") but didn't, nor did anyone else to bother with the checkpatch output, etc.
> and that means there have to be people familiar enough with that
as with any new thing, one needs to learn the details of how gcc plugins work, not unlike how people had to learn the intricacies of SMP, etc along the way. i trust that more and more people will find useful things to do with gcc plugins and this lack of knowledge will disappear as it did with many other things.
|
|||||||||||||