> > Or we could stick to current mess where one has
> > to have a shitload of crosscompiles and CPU power to check even trivial
> > changes to a few include files.
>
> We _are_ stuck with it.
For old stuff - to a high degree yes.
> > Partly this could be fixed by making header files in asm-$(ARCH)
> > second class citizen - that always got included via their linux/
> > counterpart.
>
> Which only makes dependency graph fatter... What's the difference
> between including asm/uaccess.h and linux/uaccess.h?
It makes it fatter on the horizontal level - yes.
But then files do not rely on files being included by asm-* files
anymore - so less difference between architecutes.
> Basically, you pull tons of includes into linux/blah.h because it
> happens to include asm/foo.h and _that_ depends on having linux/barf.h
> for $WEIRD_TARGET.
That would be wrong. Any file in asm-* that needs a file from linux/
should pull that include to the linux/ counterpart and in this way
we are on track again.
It boils down to something simple as:
Do we want to keep arch independence lower on the price of higher number
includes in asm- counter part files in linux/?
> And guess what? You are back to the same cross-compiles,
> since attempt to remove blah.h -> barf.h will break $WEIRD_TARGET, but
> you won't notice that unless you cross-compile for it.
No.
There is a huge difference modifying architecture independent code like
infiniband or module.c and to try to clean up headers.
Cleaning up headers really really require that one cross compile
a lot no matter how files are organized.
> So all you get is a bunch of harder to explain includes between linux/*.h,
> _and_ extra dependencies that make no sense whatsoever.
They are easy to explain: They are there to keep arch independence lower -
and the cost is a number (tons?) of extra includes.
OK - this was a fun thread talking about arch specific includes.
But since I do not plan to follow-up with patches I will
drop of for now. bugzilla and others tell me I should concentrate
on other things.
Sam
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]