cvs commit: src/sys/sys pbioio.h src/sys/i386/isa pbio.c src/sys/conf files.i386 src/sys/i386/conf NOTES

[Brian Fundakowski Feldman]

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 at FreeBSD.org                               \  The Power to Serve! \
 Opinions expressed are my own.                       \,,,,,,,,,,,,,,,,,,,,,,\