linux-kernel - Re: [PATCH] wait: include linux/sched.h

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:	Tue, 10 May 2011 13:07:00 +0200
From:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	"Kaywinnit L. Frye" <kaywinnit.lee.frye.2497@...il.com>,
	linux-kernel@...r.kernel.org,
	Michal Nazarewicz <m.nazarewicz@...sung.com>,
	Greg Kroah-Hartman <gregkh@...e.de>,
	Evgeny Kuznetsov <EXT-Eugeny.Kuznetsov@...ia.com>
Subject: Re: [PATCH] wait: include linux/sched.h

On Tue, 2011-05-10 at 12:36 +0200, Ingo Molnar wrote:
> 
> Obviously sched.h would include a lot of basic types to begin with, because it 
> is a fundamental 'container' type (struct task_struct) sitting at a top, 
> highlevel node of the type hierarchy - so the initial step you suggest would 
> indeed get us most of the benefits. 

I very well understand the whole header mess, and in particular last
time I looked at the sched.h vs wait.h thing simply removing the non
sched.c related things was enough to resolve this particular problem.

I really don't like the foo_type.h headers much and think we should only
use them as absolute last resort solutions.

I might have mis-read your email, but to me your:

  "To fix these super-headers like sched.h and to make wait.h
self-sufficient the right and cleanest approach would be to split data
types and primitive accessor functions.."

Seems to suggest to begin with that split, instead of starting with sane
cleanups like moving the signal and process (groups of tasks) bits out
into their own headers.

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