lkml.org 
[lkml]   [2009]   [Feb]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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


\
 
 \ /
  Last update: 2009-02-03 23:41    [W:0.153 / U:0.100 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site