linux-kernel - Re: [PATCH] missing includes from infiniband merge

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20060924215625.GA27605@uranus.ravnborg.org>
Date:	Sun, 24 Sep 2006 23:56:25 +0200
From:	Sam Ravnborg <sam@...nborg.org>
To:	Al Viro <viro@....linux.org.uk>
Cc:	Linus Torvalds <torvalds@...l.org>, rolandd@...co.com,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] missing includes from infiniband merge

> > 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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/