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] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 24 Sep 2006 22:52:44 +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

On Sun, Sep 24, 2006 at 08:19:17PM +0100, Al Viro wrote:
> 
> > Looking through asm-i386/io.h at fist look there is zero use of
> > linux/vmalloc.h so the include has no business there.
> 
> There are obvious asm/page.h uses, so just ripping it out won't be enough.
> Even for that particular case.  And we have shitloads of places were
> asm-foo/bar.h genuinely needs linux/baz.h for e.g. implementation of
> an inlined helper.  With other targets not needing it at all.  Would you
> mandate including it from every user of asm/foo.h?  And maintain such
> rules afterwards ("asm/foo.h needs linux/baz.h included before it since
> on $WEIRD_TARGET we include asm/unique_turd.h that won't compile unless
> linux/baz.h will be aready there").

The only thing I like to see is minimal suprise. And minimal suprise in
this case is to be considered as "works on almost all archs if not all".
In practical terms it could be that users of asm/* had to include
baz.h before bar.h. 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.

Partly this could be fixed by making header files in asm-$(ARCH)
second class citizen - that always got included via their linux/
counterpart.

Take a look at uaccess.h for example.
A grep shows that most architectures include almost the same header files
with a few that require string.h.
So it would be so simple to move the include of string.h to the
linux/uaccess.h counter part and no arch specific dependencies.

Grepping the tree I only find one user of linux/uaccess.h : filemap.*
But even though my point holds that there are easy way to deal with this
without the maintenace nightmare you try to picture up.

That said this would maybe work in two third of the cases and is no
bullet proof solution. But each time we can decrease the arch differences
we are one step in the right direction.

	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/