Date: Mon, 12 Jul 1999 18:21:26 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: Peter Jeremy <jeremyp@gsmx07.alcatel.com.au> Cc: dfr@nlsystems.com, dillon@apollo.backplane.com, freebsd-current@FreeBSD.ORG, luoqi@watermarkgroup.com, mike@ducky.net Subject: Re: "objtrm" problem probably found Message-ID: <199907130121.SAA73158@apollo.backplane.com> References: <99Jul13.084657est.40574@border.alcanet.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
:Or (maybe more clearly):
:
:#ifdef SMP
:#define SMP_LOCK "lock; "
:#else
:#define SMP_LOCK
:#endif
:
:#define ATOMIC_ASM(type,op) \
: __asm __volatile (SMP_LOCK op : "=m" (*(type *)p) : "ir" (v), "0" (*(type *)p))
Yes, precisely.
:I believe the API to the PCI-locking routines should be distinct from
:the API for SMP locks - even though the underlying implementation may
:be common.
This is more a driver issue then anything else.
:Based on the impact above, I believe the lock prefixes should not
:be inserted until they are necessary - even if it does mean we wind
:up with /modules and /modules.smp. I don't believe that moving
:to indirect function pointers is a reasonable work-around.
:
:Peter
We can certainly remove it for the UP case, but it needs to stay in
for the SMP case because there is a 100% chance that these routines
are going to have to be SMP safe when the big giant lock hits up against
the VM system. It will become even more important after interrupts are
moved into their own threads if we want to be able to run interrupts
in parallel with other supervisor code (e.g. network interrupt and network
stack ).
-Matt
Matthew Dillon
<dillon@backplane.com>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199907130121.SAA73158>