Date: Tue, 01 Nov 2005 12:51:02 -0700 From: Scott Long <scottl@samsco.org> To: Dinesh Nair <dinesh@alphaque.com> Cc: freebsd-hackers@freebsd.org, Julian Elischer <julian@elischer.org> Subject: Re: locking in a device driver Message-ID: <4367C726.8070405@samsco.org> In-Reply-To: <4367C07C.1040900@alphaque.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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 > >> 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?4367C726.8070405>