From: Grant Grundler <grundler@parisc-linux.org>
To: Ingo Molnar <mingo@elte.hu>
Cc: parisc-linux@parisc-linux.org, Matthew Wilcox <matthew@wil.cx>
Subject: [parisc-linux] Re: [patch] spinlock consolidation, v2
Date: Mon, 13 Jun 2005 12:39:32 -0600 [thread overview]
Message-ID: <20050613183932.GA9457@colo.lackof.org> (raw)
In-Reply-To: <20050613074407.GA13878@elte.hu>
On Mon, Jun 13, 2005 at 09:44:07AM +0200, Ingo Molnar wrote:
> > BTW, I do not like "void *" if we can (and should) use a special
> > typedef.
>
> yeah, agreed - that was just a quick hack, to see whether the dependency
> problem is sorted out via it.
Understood - I just don't think it's worth solving this problem generically
by dropping the type checking. I think this problem is unique to parisc.
No matter how we sliced and dice it, bitops and spinlock will collide
on parisc.
> (i'm not sure it will be resolved) I'd
> like to address these dependency problems without having to change any
> spinlock to raw_spinlock.
I don't want to hold up your patch since I believe it's a step
in the right direction. I'm ok with changing to a raw_spinlock_t
for bitops.h for now.
Thinking more about circular dependency. It's basically
something like this:
bitops.h depends on atomic.h for _atomic_spin_lock_irqsave/et al.
atomic.h depends on spinlock.h for _raw_spin_lock* to
define _atomic_spin_lock_irqsave/et al.
linux/spinlock.h now depends on asm/atomic.h for atomic_t
definition used in _atomic_dec_and_lock().
The next step may to seperate the definition of atomic_t (e.g moving
that to asm/types.h) from the inline code (usage) and function prototypes.
ie have 4 header files:
spinlock_types.h /* spinlock_t, SPIN_UNLOCKED, et al */
spinlocks /* spin_lock_*() */
atomic_types.h /* atomic_t */
atomic.h /* _atomic_spin_lock_*(), __xchg(), et al */
Then linux/spinlock.h can include asm/atomic_types.h to get just the
subset it needs. asm/atomic.h will have to include linux/spinlock.h
then to use regular spinlocks then. TBH, I don't like the general idea
of an asm/*.h depending on a linux/*.h (atomic.h including spinlock.h
respectively in this case). But could live with it if you feel strongly
about no one using _raw_spinlocks directly.
thanks,
grant
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
next prev parent reply other threads:[~2005-06-13 18:39 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-06-03 17:31 [parisc-linux] [mingo@elte.hu: [patch] spinlock consolidation, v2] Matthew Wilcox
2005-06-04 11:55 ` Joel Soete
2005-06-04 18:03 ` Grant Grundler
2005-06-05 19:13 ` Joel Soete
2005-06-06 6:05 ` [parisc-linux] Re: [patch] spinlock consolidation, v2 Grant Grundler
2005-06-06 7:36 ` Ingo Molnar
2005-06-06 15:12 ` Grant Grundler
2005-06-06 16:31 ` Ingo Molnar
2005-06-06 17:55 ` Grant Grundler
[not found] ` <20050606175029.GC24437@colo.lackof.org>
2005-06-12 6:49 ` Ingo Molnar
2005-06-12 7:25 ` Grant Grundler
2005-06-12 7:34 ` Ingo Molnar
2005-06-13 6:29 ` Grant Grundler
2005-06-13 7:44 ` Ingo Molnar
2005-06-13 18:39 ` Grant Grundler [this message]
2005-06-21 11:22 ` Ingo Molnar
[not found] <20050607180315.GH29220@colo.lackof.org>
[not found] ` <4282FEEC0000AB95@mail-3-bnl.tiscali.it>
2005-06-08 16:05 ` Grant Grundler
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=20050613183932.GA9457@colo.lackof.org \
--to=grundler@parisc-linux.org \
--cc=matthew@wil.cx \
--cc=mingo@elte.hu \
--cc=parisc-linux@parisc-linux.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.