linux-kernel - Re: 2.6.18 Headers

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:	Sat, 15 Jul 2006 08:19:42 +0100
From:	David Woodhouse <dwmw2@...radead.org>
To:	Jim Gifford <maillist@...55.com>
Cc:	David Miller <davem@...emloft.net>, arjan@...radead.org,
	linux-kernel@...r.kernel.org, ralf@...ux-mips.org
Subject: Re: 2.6.18 Headers - Long

On Fri, 2006-07-14 at 13:57 -0700, Jim Gifford wrote:
> Do we have a list of what headers are "user-space" and which ones should 
> not be "user-space"?

Well, we have the lists in include/*/Kbuild files, of course -- but
that's all. As I've stated before, I've been somewhat liberal with the
exports to far, to match what's currently (ab)used, because I wanted to
concentrate on the _mechanism_, not the policy.

The intention is that we can now start to tighten it up -- I've already
sent the patches which drop asm/atomic.h and asm/io.h, and there are
more which should go. Next on that list (and already commented as such
in include/asm-generic/Kbuild.asm) are asm/page.h and asm/elf.h.

> Also David W, let me know what I can do to help you out, a lot of people 
> on my end want to get this working properly.

Thanks. One thing you can do which would be extremely useful is to
investigate dropping page.h and elf.h, and make sure that stuff like gdb
(and anything using ptrace.h) will still build. Then just look for
anything else which should be removed from view. The git repository at
http://git.kernel.org/git/?p=linux/kernel/git/dwmw2/kernel-headers.git
(git://git.kernel.org/pub/scm/linux/kernel/git/dwmw2/kernel-headers.git)
should help with that task. Provide patches to move stuff within #ifdef
__KERNEL__ or to move it to unexported files.

There are some who think that it would be nice to get rid of __KERNEL__
entirely -- files would be either entirely exported, or not at all. I
don't think we necessarily need to go that far; the export step with
unifdef isn't so bad.

-- 
dwmw2

-
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/