linux-kernel - Re: [PATCH v2] sched: fix build error in kernel/sched_rt.c when RT_GROUP

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 for Android: free password hash cracker in your pocket

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

Date:	Wed, 14 Jan 2009 12:03:56 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Gregory Haskins <ghaskins@...ell.com>, rostedt@...e.goodmis.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] sched: fix build error in kernel/sched_rt.c when
	RT_GROUP_SCHED && !SMP


* Peter Zijlstra <peterz@...radead.org> wrote:

> On Wed, 2009-01-14 at 09:01 +0100, Ingo Molnar wrote:
> > * Gregory Haskins <ghaskins@...ell.com> wrote:
> > 
> > > +#define dec_rt_group(rt_se, rt_rq) do { } while (0)
> > 
> > Please dont _ever_ introduce new CPP macros into core kernel code, and if 
> > you see existing once, please fix them to be proper C inline functions. 
> > (there's a few other new macros in your patchset)
> 
> Generally good advice, and certainly doable in this case. But in some 
> very rare occasions I've had to use CPP in order to avoid silly header 
> dependency hell -- I think we should add comments in such cases as to 
> why we use CPP.

yeah - that's why i qualified it with 'core kernel code', not 'headers'. 

(But even in the dependency spaghetti case the right solution is to clean 
up the header dependencies. It's just very hard in most cases due to most 
folks running on x86 and there being 20+ other architectures they cannot 
really test. So the dependency hell tends to grow not shrink. )

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