Date: Tue, 30 Apr 2002 16:41:36 -0600 From: Warner Losh <imp@harmony.village.org> To: Bruce Evans <bde@zeta.org.au> Cc: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/dev/wi wi_hostap.c Message-ID: <200204302241.g3UMfab87030@harmony.village.org> In-Reply-To: Your message of "Wed, 01 May 2002 02:44:23 %2B1000." <20020501020252.W11154-100000@gamplex.bde.org> References: <20020501020252.W11154-100000@gamplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <20020501020252.W11154-100000@gamplex.bde.org> Bruce Evans writes: : On Mon, 29 Apr 2002, Warner Losh wrote: : > splsoftnet is spelled splimp in FreeBSD rather than splnet. splimp is : > used to protect the rest of the driver. This is a no-op commit to current, : > but is needed for the MFC. : : Er, this is perfectly backwards in at least the log message. splsoftnet : in NetBSD is spelled splnet in FreeBSD. splnet in NetBSD is spelled splimp : in FreeBSD. Changing splnet to splimp just increases interrupt latency. OK. splimp() is used in the rest of the wi driver, and I really need to go through wi_hostap.c using the same locking stuff I changed in if_wi.c. Current works because of Giant. : This file also misuses splsoftclock. splsoftclock has different : semantics in FreeBSD. Using it is at best a hack except in the one : place where it has the correct semantics (in hardclock() in RELENG_4), : and even in that place its use is dubious -- it only works right on : some machines, not including i386's (so it is not used on i386's). : Drivers should use a device-specific spl to mask softclock interrupts : (splnet for network drivers). OK. I'm not understanding what you are saying here. Should I just use splimp as well? The spl stuff is underdocumented at the moment. : More details: splsoftclock in NetBSD raises the priority to that of : softclock (timeouts), but in FreeBSD it _sets_ the priority that of : softclock. Since softclock (at lease in FreeBSD) is lower than all other : priorities except 0, splsoftclock in only raises the priority if the : priority is 0; it has no effect if the priority is already softclock and : _lowers_ the priority otherwise. Lowering the priority is usually wrong. OK. I'll be happy to fix the abuse. I just wanted a way to make sure that I locked out the callback while I was modifying it. : > MFC after: 1 day : : Doesn't seem to be long enough for finding bugs, especially when the bugs : are no-ops in -current. I'll admit that I was rushing to get things into -current due to the impending freeze. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200204302241.g3UMfab87030>