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

[Scott Long]

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.

Scott