Re: [RFC] typechecking for get_unaligned/put_unaligned

[Al Viro]

On Mon, Oct 16, 2006 at 06:50:54PM -0700, Linus Torvalds wrote:

> > 	c) how about gradually switching to linux/unaligned.h?
> 
> I'd prefer not to, if only because it's an unnecessary compile-time 
> overhead for nice sane architectures like x86, which don't need any of the 
> unaligned crap.
> 
> Since x86[-64] is clearly the main architecture, dis-optimizing for that 
> one sounds like a bad idea.

Hrm...  I'm not sure that I buy that argument - we have relatively few
callers of these suckers and I doubt that it will affect compile time
in a measurable way.  FWIW, that reminds me - I ought to resurrect the
patchset killing bogus dependencies; I modified sparse to collect stats
on how many times each #include actually pulls a header during build,
added those to data on dependencies (from .cmd.*) and got interesting results.

There are several #includes with very high impact; the worst happens
to be module.h -> sched.h, followed by several includes of fs.h.  These
turned out to be easy to kill (i.e. few places actually needed compensatory
#include added) and that had seriously cut down on total dependencies.
The patches will need to be redone due to bitrot, but they are not
hard to reproduce.  The really interesting observation is that such
high-impact includes exist and can be found by this technics...

As for get_unaligned() and friends...  Dunno.  The thing is, most of
the targets have them with piss-poor type safety (e.g. asm-generic
put_unaligned() starts with casting val to __u64; there goes any chance
to get any useful warnings from cc(1) *and* we get fun warnings from
sparse every bloody time we use it on __be32, etc.).

I can fix those one by one, but I still think that it would be better
to keep the typechecking in one place...

PS: while a few hundreds of callers per allmodconfig build are minor noise
in compile time, the noise from a few hundreds of bogus warnings is
quite considerable ;-)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/