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:47:45PM -0600, Scott Long wrote:
> Brian Fundakowski Feldman wrote:
> >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'll have to look at my notes from past discussions.  I think that the
> goal was to make the ops look more like what they do in NetBSD, which
> has the notion of being in the perspective of the DMA engine that is
> doing the transfer, not from the perspective of the host CPU.  Anyways,
> this is one of many things that need to change, but I'd like to hold off
> further discussions until 5.3 is done and I have time to think about it.
> 
> >
> >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.
> >
> 
> Let's not fall into this old trap.  Yes, there are definite
> inconsistencies between mapping dynamic buffers and static buffers, and
> we should take that into account and fix it.  Again, I'd have a lot of
> notes on this but won't be able to do anything with them for a few more
> weeks.

Thank you, this is all very good to hear :)  I'll look forward to seeing
the subject raised on -arch once 5.3 is out the door.

-- 
Brian Fundakowski Feldman                           \'[ FreeBSD ]''''''''''\
  <> green at FreeBSD.org                               \  The Power to Serve! \
 Opinions expressed are my own.                       \,,,,,,,,,,,,,,,,,,,,,,\