Date: Tue, 26 Feb 2002 08:38:38 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: John Baldwin <jhb@FreeBSD.org> Cc: Bruce Evans <bde@zeta.org.au>, Terry Lambert <tlambert2@mindspring.com>, Alfred Perlstein <alfred@FreeBSD.org>, Bosko Milekic <bmilekic@unixdaemons.com>, Seigo Tanimura <tanimura@r.dl.itc.u-tokyo.ac.jp>, current@FreeBSD.org Subject: Re: Patch for critical_enter()/critical_exit() & interrupt assem Message-ID: <200202261638.g1QGccQ59999@apollo.backplane.com> References: <XFMail.020226100234.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
:.. :> cpu_critical_enter() to a null version to prevent spinlocks masking :> interrupts doesn't work very well because it is used for other things :> that really do need to mask interrupts. Having 2 levels for :> cpu_critical_enter() (on that masks normal interrupts and one that :> masks fast interrupts) would work but I think there are already too :> many levels of critical_enter()s. : :I think having the sparc-like API of intr_disable() / intr_restore() that we :used to use to fix the places that assume too many implementation details of :cpu_critical_foo() would be a good first step so that cpu_critical_foo() can be :relegated back to supporting non-preemption (and no other spinlocks) and :nothing else. : :> Bruce : :-- : :John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/ I consider this a mistake that inappropriately locks MI code into architecture-specific (MD) features, especially considering that there are only two places in the codebase that actually make this assumption right now and both can be easily fixed. It makes no sense to me to abstract out a third API (let alone making cpu_critical_*() available to the MI code) when the existing critical_*() API will do the job just fine. -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?200202261638.g1QGccQ59999>