From owner-svn-src-projects@FreeBSD.ORG Sun Jun 6 08:06:17 2010 Return-Path: Delivered-To: svn-src-projects@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DC3C3106566B; Sun, 6 Jun 2010 08:06:17 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 768A48FC22; Sun, 6 Jun 2010 08:06:17 +0000 (UTC) Received: from [127.0.0.1] (pooker.samsco.org [168.103.85.57]) (authenticated bits=0) by pooker.samsco.org (8.14.4/8.14.4) with ESMTP id o56868bk003445; Sun, 6 Jun 2010 02:06:08 -0600 (MDT) (envelope-from scottl@samsco.org) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Scott Long In-Reply-To: Date: Sun, 6 Jun 2010 02:06:08 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201006052041.o55KfMF6032155@svn.freebsd.org> <184A275D-B98A-4DBF-9F4D-22F27B9319DD@mac.com> <20100605.203348.651115405925906974.imp@bsdimp.com> <516EEDC6-069A-4780-84DF-BBFF43ABCDE5@samsco.org> To: Marcel Moolenaar X-Mailer: Apple Mail (2.1078) X-Spam-Status: No, score=-50.0 required=3.8 tests=ALL_TRUSTED, T_RP_MATCHES_RCVD autolearn=unavailable version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on pooker.samsco.org Cc: svn-src-projects@FreeBSD.org, src-committers@FreeBSD.org, nwhitehorn@FreeBSD.org, "M. Warner Losh" Subject: Re: svn commit: r208850 - projects/ppc64/sys/powerpc/include X-BeenThere: svn-src-projects@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the src " projects" tree" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jun 2010 08:06:17 -0000 On Jun 5, 2010, at 9:49 PM, Marcel Moolenaar wrote: >=20 > On Jun 5, 2010, at 8:38 PM, Scott Long wrote: >=20 >> On Jun 5, 2010, at 8:33 PM, M. Warner Losh wrote: >>> In message: <184A275D-B98A-4DBF-9F4D-22F27B9319DD@mac.com> >>> Marcel Moolenaar writes: >>> :=20 >>> : On Jun 5, 2010, at 1:41 PM, Nathan Whitehorn wrote: >>> :=20 >>> : > Author: nwhitehorn >>> : > Date: Sat Jun 5 20:41:22 2010 >>> : > New Revision: 208850 >>> : > URL: http://svn.freebsd.org/changeset/base/208850 >>> : >=20 >>> : > Log: >>> : > BUS_SPACE_UNRESTRICTED is a flag, not an address, so it should = be an int, >>> : > not a long. >>> :=20 >>> : This probably isn't right. How would you distinguish between a = 32-bit >>> : maximum of and unlimited if both can have the value 0xFFFFFFFF. >>> : Making BUS_SPACE_UNRESTRICTED a long prevents zero-extension to = 64-bit >>> : and thus prevents this ambiguity. >>>=20 >>> But this define is used for busdma's number of segments. It isn't >>> used for an address at all... >>>=20 >>> from the busdma man page for bus_dma_tag_create: >>> nsegments Number of discontinuities (scatter/gather = segments) >>> allowed in a DMA mapped region. If there is = no >>> restriction, BUS_SPACE_UNRESTRICTED may be = speci- >>> fied. >>>=20 >>> so an argument consistent with the definition of nsegments is what = is >>> needed. The man page doesn't specify a type for nsegments, but >>> sys/bus_dma.h defines it as: >>>=20 >>> int bus_dma_tag_create(bus_dma_tag_t parent, bus_size_t alignment, >>> bus_size_t boundary, bus_addr_t lowaddr, >>> bus_addr_t highaddr, bus_dma_filter_t *filtfunc, >>> void *filtfuncarg, bus_size_t maxsize, int = nsegments, >>> bus_size_t maxsegsz, int flags, bus_dma_lock_t = *lockfunc, >>> void *lockfuncarg, bus_dma_tag_t *dmat); >>>=20 >>> so it is more proper to have it be an int than a long. >>>=20 >>> I got tripped up on this stupid name too when I was adding it for >>> MIPS. Any why it is in a MD file instead of an MI file is beyond = me. >>> I think it should be defined in sys/bus_dma.h, but maybe I'm just = nuts... >>>=20 >>=20 >> No, you're not nuts. I've had a grand unification of MI/MD parts of = busdma on my mind for years, and probably at least 2 or 3 aborted = attempts lying around in old defunct trees. Any unification is going to = risk API/ABI changes, so I ultimately don't want to do it simply for = cleanliness sake. =20 >=20 > Scott, >=20 > I've started an unification on the Altix branch myself because I > need to add I/O MMU support for ia64 in order to get FreeBSD booting > on the SGI Altix (there's no physical memory under 4GB so bounce > buffering is impossible). If I need to work on busdma, I'd rather > unify the whole lot so that other platforms can use I/O MMU when > it's present. >=20 > Can you send me whatever you have or have done before so that I > can leverage. >=20 > BTW: my current approach is to take the amd64 implementation as a > base, and move platform specific code back into MD code. >=20 > Also: if there's interest among more people, we should probably > create a special branch for it and work together. >=20 I struggle with answering the question of whether to just reorg the = interface definitions but leave the interface alone, or whether to = rewrite the interface definitions in the context of having a new DMA = api. There are a lot of things that I like about busdma, and a lot of things = that I dislike. Some things are simply too hard, clunky, and = inflexible, like allocating static memory for DMA. I like the two-stage = load paradigm for i/o bufs, but it's really not appropriate for anything = besides I/O, and I wonder if it'll start to be a performance liability = as i/o transaction speed reaches network transaction levels. I really = don't like the inconsistency and confusion in the naming of certain = functions and constants, something clearly brought out in this thread. = I don't like that simply allocating a tag is a daunting task for sorting = out and supplying 14 argument. There's probably a few other things that = I'd really like to change, too. So the question is where to start and = how far to go. Does it make sense to preserve the existing interface = and layer a new meta-interface on top of it? Or does it make sense to = just change everything in-place and make a clean break from the past? = Or like I said before, is a "new" interface really not that important, = with the important thing being to clean up the glaring problems in the = existing interface. =20 On the specific topic of BUS_SPACE_UNRESTRICTED, that's a definition = that seems to have been "borrowed" from the bus_space API. Maybe at one = time there was a desire to marry bus_space (bus.h) and bus_dma together = in some fashion, but I don't see that having any practical value now. = bus_dma.h and bus.h are separate interfaces and shouldn't be sharing = definitions, as far as I'm concerned. If there are any disagreements on = this, I'm happy to hear them. Scott