From owner-freebsd-current Mon Jul 12 18:21:47 1999 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 3EA8F15230 for ; Mon, 12 Jul 1999 18:21:41 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id SAA73158; Mon, 12 Jul 1999 18:21:26 -0700 (PDT) (envelope-from dillon) Date: Mon, 12 Jul 1999 18:21:26 -0700 (PDT) From: Matthew Dillon Message-Id: <199907130121.SAA73158@apollo.backplane.com> To: Peter Jeremy Cc: dfr@nlsystems.com, dillon@apollo.backplane.com, freebsd-current@FreeBSD.ORG, luoqi@watermarkgroup.com, mike@ducky.net Subject: Re: "objtrm" problem probably found References: <99Jul13.084657est.40574@border.alcanet.com.au> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message