From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 1 22:12:42 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 282C216A422 for ; Tue, 1 Nov 2005 22:12:42 +0000 (GMT) (envelope-from julian@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id D39C043D46 for ; Tue, 1 Nov 2005 22:12:41 +0000 (GMT) (envelope-from julian@elischer.org) Received: from unknown (HELO [10.251.23.117]) ([10.251.23.117]) by a50.ironport.com with ESMTP; 01 Nov 2005 14:12:41 -0800 X-IronPort-Anti-Spam-Filtered: true Message-ID: <4367E858.6000506@elischer.org> Date: Tue, 01 Nov 2005 14:12:40 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.11) Gecko/20050727 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Scott Long References: <4360B8EE.4070605@alphaque.com> <4360DD7B.20900@samsco.org> <4361044B.50807@alphaque.com> <20051027.205250.55834228.imp@bsdimp.com> <4361E3E0.4090409@alphaque.com> <43676121.4030801@alphaque.com> <436791ED.8010808@samsco.org> <4367AA8D.3060506@alphaque.com> <4367BBDB.7020005@elischer.org> <4367C07C.1040900@alphaque.com> <4367C726.8070405@samsco.org> In-Reply-To: <4367C726.8070405@samsco.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: locking in a device driver X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2005 22:12:42 -0000 Scott Long wrote: > Dinesh Nair wrote: > >> >> >> On 11/02/05 03:02 Julian Elischer said the following: >> >>> drops to splzero or similar,.. >>> woken process called, >>> starts manipulating "another buffer" >>> collides with next interrupt. >> >> >> >> that makes a lot of sense, i'll try with using splxxx() in the pseudo >> driver, to block out the real driver. it's currently splhigh() due to >> INTR_TYPE_MISC being used, but i guess i could change this to >> INTR_TYPE_NET or INTR_TYPE_TTY. what would be good for a >> telecommunications line card which is time sensitive and interrupts >> at a constant 1000Hz ? > > > INTR_TYPE_TTY and spltty depends on what they are using it for.. if it's a WAN interface, then splimp. (INTR_TYPE_NET) if ppp or several other moduels are loaded, teh tty and net masks are combined anyhow.. > >> >>> it needs to call splxxx() while it is doing it.. >>> I would suggest having two buffers and swapping them under splxxx() >>> so that >>> the one that the driver is accessing is not the one you are draining. >>> that way teh splxxx() levle needs to only be held for the small >>> time you are doing the swap. >> >> >> >> >> the first buffer is actually the buffer into which DMA reads/writes >> are done. what i referred to as "another buffer" is in fact a ring of >> buffers. the real driver writes into the top of the ring, and >> increments the top ring pointer. the pseudo driver reads from the >> bottom of the ring and increments the bottom ring pointer. >> >> buf1 buf2 buf3 buf4 buf5 buf6 buf7 buf8 >> ^ ^ >> | | >> | +-- top ring pointer, incremented as real driver reads >> | from device >> +-- bottom ring pointer, incremented as userland reads from pseudo >> > > You'll also want to use an spl in the top half of the pseudo driver to > cover where the pointers are read and changed. > >> >>> not locks, but spl, >>> and only step 8 needs to be changed because all teh rest are already >>> done at high spl. >> >> >> >> wouldnt a lockmgr() around the access to these ring buffers help >> since we're locking access to data and not necessarily execution ? >> > > lockmgr is far to heavy-weight and complex for this. > > Scott