Date: Tue, 01 Nov 2005 14:12:40 -0800 From: Julian Elischer <julian@elischer.org> To: Scott Long <scottl@samsco.org> Cc: freebsd-hackers@freebsd.org Subject: Re: locking in a device driver Message-ID: <4367E858.6000506@elischer.org> In-Reply-To: <4367C726.8070405@samsco.org> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4367E858.6000506>