Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 07 Oct 2004 17:06:10 -0600
From:      Scott Long <scottl@FreeBSD.org>
To:        Brian Fundakowski Feldman <green@FreeBSD.org>
Cc:        Warner Losh <imp@FreeBSD.org>
Subject:   Re: cvs commit: src/sys/sys pbioio.h src/sys/i386/isa pbio.csrc/sys/conf files.i386 src/sys/i386/conf NOTES
Message-ID:  <4165CBE2.9020906@FreeBSD.org>
In-Reply-To: <20041007224300.GF73261@green.homeunix.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>

next in thread | previous in thread | raw e-mail | index | archive | help
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.

Scott



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4165CBE2.9020906>