All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Ingo Molnar <mingo@elte.hu>
Cc: jeremy@goop.org, jaswinderrajput@gmail.com,
	randy.dunlap@oracle.com, linux-kernel@vger.kernel.org,
	x86@kernel.org, righi.andrea@gmail.com
Subject: Re: mmotm 2009-02-02-17-12 uploaded (x86/nopmd etc.)
Date: Wed, 4 Feb 2009 13:25:29 -0800	[thread overview]
Message-ID: <20090204132529.4b77dd4a.akpm@linux-foundation.org> (raw)
In-Reply-To: <20090204200846.GF22608@elte.hu>

On Wed, 4 Feb 2009 21:08:46 +0100
Ingo Molnar <mingo@elte.hu> wrote:

> 
> * Andrew Morton <akpm@linux-foundation.org> wrote:
> 
> > > > This is getting painful.
> > > 
> > > 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! ;-)
> > > 
> > > 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.
> > 
> > I like this one.  The mixing up of declare-something with use-something
> > is often the source of our woes.
> 
> yes. I mapped this problem area once and this is how the include file 
> spaghetti gets generated in practice:
> 
>   - type A gets declared
>   - type A gets _used_ in the same file in an inline method, BUT,
> 
>       that usage also brings in instantiated use of type X1, X2 and X3.
> 
> if all types are declared like that everywhere, it can be seen (and it's a 
> mathematical certainty) that the only conflict-free way of doing this is to:
> 
>   - initially add random #include lines to bring in type X1, X2 and X3. 
>     Which brings in recursive dependencies from those X1 X2 and X3 files.
> 
>   - when the stuff hits the fan then folks are in a big mess already and 
>     only a deep restructuring could gets them out of it - which they rarely 
>     do in an iterative environment. So they work it around iteratively: 
>     instead of new nice inline methods [which we really prefer] they delay 
>     all the 'usage' instantiation to .c file via the use of CPP macros 
>     [which we hate because they hide bugs and cause bugs].

None of which would happen if we didn't also have an inlining fetish.


  reply	other threads:[~2009-02-04 21:26 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-03  1:12 mmotm 2009-02-02-17-12 uploaded akpm
2009-02-03 18:58 ` mmotm 2009-02-02-17-12 uploaded (x86/nopmd etc.) Randy Dunlap
2009-02-03 19:18   ` Ingo Molnar
2009-02-03 20:17     ` Andrew Morton
2009-02-03 21:25       ` Ingo Molnar
2009-02-03 21:41         ` Andrew Morton
2009-02-04 20:08           ` Ingo Molnar
2009-02-04 21:25             ` Andrew Morton [this message]
2009-02-04 21:29               ` Ingo Molnar
2009-02-04 21:32               ` Andrea Righi
2009-02-03 22:37         ` Jeremy Fitzhardinge
2009-02-04 19:56           ` Ingo Molnar
2009-02-03 22:13 ` [PATCH] sunrpc: fix rdma dependencies Randy Dunlap
2009-02-03 23:20   ` David Miller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090204132529.4b77dd4a.akpm@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=jaswinderrajput@gmail.com \
    --cc=jeremy@goop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=randy.dunlap@oracle.com \
    --cc=righi.andrea@gmail.com \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.