| |||||||||||||
Better kernels with GCC pluginsBetter kernels with GCC pluginsPosted Oct 13, 2011 18:55 UTC (Thu) by vonbrand (subscriber, #4458)In reply to: Better kernels with GCC plugins by callegar Parent article: Better kernels with GCC plugins
What I worry about is that PaX_C ends up being an opaque language, in which all sort of magic happens behind the scenes ("a struct full of function pointers gets to be const, unless..."). The central virtue of C (instead of, say, C++) is its transparency, which has been derided as "high-level assembly language": What you write is translated rather straightforwardly into what gets executed. Sure, C has its grave faults, extra tools for checking what you write are a must (thankfully the days of
(Log in to post comments)
Better kernels with GCC plugins Posted Oct 14, 2011 21:51 UTC (Fri) by PaXTeam (subscriber, #24616) [Link]
what if you stopped spreading FUD? there isn't any magic behind the scenes, the source code of the plugins is freely available. if you don't understand the code then it's your own problem, but that doesn't justify the FUD you're trying to spread.
as for C being a "high-level assembly language" and "is translated rather straightforwardly into what gets executed", it's never been true, one needs to look no further than all the undefined behaviours the current linux code triggers.
Better kernels with GCC plugins Posted Oct 16, 2011 4:03 UTC (Sun) by quotemstr (subscriber, #45331) [Link]
With an attitude like yours, I can understand PaX team has a hard time getting code into the kernel. The OP is in no way spreading FUD, and claiming that he is reflects more on you than it does him. The OP's point, which is that semantics differing markedly from ordinary C make code less readable, is perfectly valid. When code becomes opaque, it's not "your own problem": it's a problem for the entire community, increasing barriers to entry and ongoing maintenance costs for everyone. It would behoove you to actually address this point.
The compiler plugin source being available is no defense: INTERCAL sources are available too, but this fact doesn't make INTERCAL comprehensible.
Better kernels with GCC plugins Posted Oct 16, 2011 11:06 UTC (Sun) by PaXTeam (subscriber, #24616) [Link]
> With an attitude like yours, I can understand PaX team has a hard time getting code into the kernel.
given that i don't even try (lately that is, in previous years i got many bugfixes in without much hassle), i can't see how you managed to draw that conclusion ;).
> The OP is in no way spreading FUD, and claiming that he is reflects more on you than it does him.
and claiming that he doesn't reflects more on you than it does on me? can we skip the silly rhetoric please?
> The OP's point, which is that semantics differing markedly from ordinary
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.
> When code becomes opaque, it's not "your own problem":
you're misquoting me. i made that comment on his unwillingness to take a look at the plugin source code where he could have learned what it does. similarly how you take a look at the kernel source code if you want to learn what it does. IOW, lazyness doesn't an argument make.
> it's a problem for the entire community, increasing barriers to entry
why does a constification plugin increase the barriers to entry?
> and ongoing maintenance costs for everyone.
and what's the maintenance cost for everyone by using a constification plugin? i know its cost on me (having to check the code regularly for violations of the assumptions the plugin's based on) but a cost for *everyone*? what would that be?
also when evaluating a change one has to look at both sides of the coin, a.k.a. cost/benefit analysis. why did neither of you address the benefit side? don't see any? too little to be worth? any reasoning one can discuss?
> It would behoove you to actually address this point.
the ball's on your court now ;).
Better kernels with GCC plugins Posted Oct 16, 2011 19:14 UTC (Sun) by vonbrand (subscriber, #4458) [Link] 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.
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.
Better kernels with GCC plugins Posted Oct 26, 2011 23:54 UTC (Wed) by nix (subscriber, #2304) [Link]
Well, a lot of people seem to think C is a high-level assembly language. If you ask them to run all their code at -O0 they get rather unhappy though, so I guess they'd rather it was a language for an abstract machine, amenable to optimization. :)
|
|||||||||||||