linux-kernel - Re: mmotm 2009-02-02-17-12 uploaded (x86/nopmd etc.)

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]

Message-ID: <4988C73F.2070707@goop.org>
Date:	Tue, 03 Feb 2009 14:37:51 -0800
From:	Jeremy Fitzhardinge <jeremy@...p.org>
To:	Ingo Molnar <mingo@...e.hu>
CC:	Andrew Morton <akpm@...ux-foundation.org>,
	Jaswinder Singh Rajput <jaswinderrajput@...il.com>,
	randy.dunlap@...cle.com, linux-kernel@...r.kernel.org,
	x86@...nel.org, Andrea Righi <righi.andrea@...il.com>
Subject: Re: mmotm 2009-02-02-17-12 uploaded (x86/nopmd etc.)

Ingo Molnar wrote:
> the include file spaghetti is ... interesting there, and it's historic.
>
> I could blame it on highmem, PAE or paravirt - but i'll only blame it on 
> paravirt for now because those developers are still around! ;-)
>   

Hey, don't forget unification, if we're pointing fingers ;)

> Jeremy, any ideas how to reduce the historic dependency mess in that area?
> I think we should go on three routes at once:
>
>  - agressive splitup and separation of type definitions from method
>    declaration (+ inline definitions). The spinlock_types.h / spinlock.h 
>    splitup was really nice in solving such dependency problems.
>   

That already exists to some extent, though I don't think it's being used 
to maximum advantage (pgtable-[23]level.h vs pgtable-[23]level-defs.h).  
For consistency we'd have  pgtable-4level(-defs).h headers too, and 
top-level pgtable.h/pgtable-defs.h headers.  But its not clear to me 
that would even be enough...

>  - uninlining of methods: instead of macro-ing them - wherever possible. 
>    It's really hard to mess up type + externs headers - while headers with 
>    inlines and macros mixed in get painful quickly.
>   

Yes.  I went through a period of fairly aggressive inline->macro 
conversion, and in many cases the remaining macros are there to #include 
hell.

>  - removal of spurious pile of dozens of #include lines in header files.

Yeah, it would be useful to make sure that each header only #includes 
the bare minimum headers to satisfy its own definitions - but of course 
that's going to provoke a long series of #include whack-a-mole patches.

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