All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Roman Zippel <zippel@linux-m68k.org>
Cc: linux-kernel@vger.kernel.org, Andrew Morton <akpm@osdl.org>,
	Arjan van de Ven <arjanv@infradead.org>,
	Christoph Hellwig <hch@infradead.org>, Andi Kleen <ak@suse.de>,
	Thomas Gleixner <tglx@linutronix.de>,
	Zwane Mwaikambo <zwane@arm.linux.org.uk>
Subject: Re: [rfc] [patch] consolidate/clean up spinlock.h files
Date: Fri, 3 Jun 2005 07:16:29 +0200	[thread overview]
Message-ID: <20050603051629.GB14059@elte.hu> (raw)
In-Reply-To: <Pine.LNX.4.61.0506021817390.3743@scrub.home>


* Roman Zippel <zippel@linux-m68k.org> wrote:

> Hi,
> 
> On Thu, 2 Jun 2005, Ingo Molnar wrote:
> 
> >  - consolidates and enhances the spinlock/rwlock debugging code
> > 
> >  - simplifies the asm/spinlock.h files
> > 
> >  - encapsulates the raw spinlock types and moves generic spinlock
> >    features (such as ->break_lock) into the generic code.
> > 
> >  - cleans up the spinlock code hierarchy to get rid of spaghetti.
> 
> That nicely splits the headers into several separate files, but the 
> problem is that all these new header files are only of limited value 
> outside the spinlock code.
> What I'd really to see is a split of definitions and implementation. That 
> means the definitions would be available via <linux/spinlock_types.h> and 
> could be used in other core headers and would pull in a lot less header 
> files. Header dependencies got worse especially since preempt got 
> included.
> The patch below does the minimum to provide spinlock_types.h. We could 
> also include initializers.

yes, that's what i'm working towards - separating type from 
implementation on the arch level was the first step needed. I already 
had it at such a state yesterday (complete separation of type 
definitions, API definitions and asm implementation - it needed the 
initializers in the asm/spinlock_types.h file, but otherwise it was 
straightforward), but undid it in the last minute because sched.c and 
kernel_lock.c used some intermediate/raw primitives, leading to ugly 
dependencies. I'll re-try this angle today and repost the patch.

	Ingo

  reply	other threads:[~2005-06-03  5:17 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-06-02 14:40 [rfc] [patch] consolidate/clean up spinlock.h files Ingo Molnar
2005-06-02 15:49 ` Ingo Oeser
2005-06-02 16:16   ` Ingo Molnar
2005-06-02 16:30     ` Ingo Oeser
2005-06-02 16:34     ` Chris Friesen
2005-06-02 19:34   ` Zwane Mwaikambo
2005-06-02 17:26 ` Andi Kleen
2005-06-02 19:16 ` Roman Zippel
2005-06-03  5:16   ` Ingo Molnar [this message]
2005-06-03 11:56     ` Roman Zippel
2005-06-02 19:59 ` Zwane Mwaikambo

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=20050603051629.GB14059@elte.hu \
    --to=mingo@elte.hu \
    --cc=ak@suse.de \
    --cc=akpm@osdl.org \
    --cc=arjanv@infradead.org \
    --cc=hch@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tglx@linutronix.de \
    --cc=zippel@linux-m68k.org \
    --cc=zwane@arm.linux.org.uk \
    /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.