Date: Thu, 7 Oct 2004 19:26:53 -0400 From: Brian Fundakowski Feldman <green@FreeBSD.org> To: Scott Long <scottl@FreeBSD.org> Cc: Warner Losh <imp@FreeBSD.org> Subject: Re: cvs commit: src/sys/sys pbioio.h src/sys/i386/isa pbio.c src/sys/conf files.i386 src/sys/i386/conf NOTES Message-ID: <20041007232653.GG73261@green.homeunix.org> In-Reply-To: <4165CBE2.9020906@FreeBSD.org> References: <200410071621.i97GL3lu029620@repoman.freebsd.org> <20041007175206.GA82275@ns1.xcllnt.net> <4165C120.7040005@root.org> <4165C1EF.7020407@FreeBSD.org> <20041007224300.GF73261@green.homeunix.org> <4165CBE2.9020906@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Oct 07, 2004 at 05:06:10PM -0600, Scott Long wrote: > Brian Fundakowski Feldman wrote: > >On Thu, Oct 07, 2004 at 04:23:43PM -0600, Scott Long wrote: > > > >>Nate Lawson wrote: > >> > >>>Marcel Moolenaar wrote: > >>> > >>> > >>>>On Thu, Oct 07, 2004 at 04:21:03PM +0000, Warner Losh wrote: > >>>> > >>>> > >>>>>imp 2004-10-07 16:21:03 UTC > >>>>> > >>>>>FreeBSD src repository > >>>>> > >>>>>Modified files: > >>>>> sys/conf files.i386 sys/i386/conf NOTES > >>>>>Added files: > >>>>> sys/sys pbioio.h sys/i386/isa pbio.c Log: > >>>>>Port pbio to HEAD. > >>>> > >>>> > >>>> > >>>>I appreciate your speed, but don't you think that pbioio.h is pretty > >>>>MD given that the driver only exists on i386. Wouldn't > >>>><machine/pbioio.h> > >>>>be a better place? > >>> > >>> > >>>Also, I think our policy for both RELENG_4 and -current is new inb/outb > >>>in new drivers. The bus_space stuff is pretty easy to use so this isn't > >>>too bad a requirement. > >>> > >> > >>I agree that new code should _not_ be using unportable primitives unless > >>there is very good reason. FWIW, I plan to make vtophys(), > >>rman_get_virtual(), and other evil and i386-specific primitives very > >>hard to use in 6-CURRENT, and I will strongly oppose importing new > >>code that tries to abuse them. I was just hoping that 5.3 would pass > >>before people started testing the boundaries. > > > > > >Maybe first we should make the busdma API usable? The BUS_DMASYNC_* > >macros are named positively terribly, and the documentation really > >isn't any better. > > > > I've been discussing this exact problem with others. Once 5.3 is done > and not consuming 100% of my time, I'll start looking at this and the > other API issues that exist. Have there been any really good suggestions for sensible aliases? I would really like to make my drivers readable, and these are the best I came up with at the time: #define BUS_DMASYNC_PREDMA2CPU BUS_DMASYNC_PREREAD #define BUS_DMASYNC_POSTDMA2CPU BUS_DMASYNC_POSTREAD #define BUS_DMASYNC_PRECPU2DMA BUS_DMASYNC_PREWRITE #define BUS_DMASYNC_POSTCPU2DMA BUS_DMASYNC_POSTWRITE I'm bitter because even making an attempt to get the bus_dmamap_sync() right made busdma-ification take many times longer. That and gratuitous usage of callbacks despite making synchronous allocations were the only reasons that using the modern APIs wasn't easy as cake. -- Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\ <> green@FreeBSD.org \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20041007232653.GG73261>