Re: [RFC] typechecking for get_unaligned/put_unaligned
From: Al Viro
Date: Wed Oct 18 2006 - 02:05:35 EST
On Wed, Oct 18, 2006 at 01:42:42AM -0400, Dave Jones wrote:
> On Tue, Oct 17, 2006 at 05:37:26AM +0100, Al Viro wrote:
>
> > There are several #includes with very high impact; the worst happens
> > to be module.h -> sched.h
>
> I gave up fighting to get that fixed a year and a half ago..
> http://lkml.org/lkml/2005/1/26/11
>
> rediffing trees with lots of include file juggling gets boring real fast.
I don't see a lot of files touched by that one...
arch/i386/kernel/alternative.c | 1 +
arch/i386/kernel/cpu/mcheck/therm_throt.c | 1 +
drivers/base/cpu.c | 1 +
drivers/hwmon/abituguru.c | 1 +
drivers/leds/ledtrig-ide-disk.c | 1 +
drivers/leds/ledtrig-timer.c | 1 +
drivers/scsi/scsi_transport_sas.c | 1 +
drivers/w1/slaves/w1_therm.c | 1 +
include/asm-x86_64/elf.h | 1 -
include/linux/acct.h | 1 +
include/linux/module.h | 3 ++-
include/linux/phy.h | 2 ++
include/scsi/libiscsi.h | 2 ++
kernel/latency.c | 1 +
kernel/module.c | 2 +-
is hardly a lot.
That's the point, actually - apparently we have several high-impact includes
that are easy to sever and that are really worth being severed. The part
that was not aproiri obvious:
* there are clusters of headers around certain dependency
counts.
* such clusters tend to have leaders - header that pulls the
rest and even though other headers are apparently independently included,
all such includes end up being hidden by includes of the leader.
* gaps between the clusters are pretty large.
* dependency graph *on* *clusters* is worth being studied; includes
of cluster leader from cluster around slightly smaller dependency count
are prime targets for severing.
That is the new part here. Not just "dependency graph is a mess and ought
to be cleaned up" - _that_ is neither new nor particulary useful...
-
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/