From owner-freebsd-hackers Mon Sep 21 00:56:22 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA22158 for freebsd-hackers-outgoing; Mon, 21 Sep 1998 00:56:22 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA22151 for ; Mon, 21 Sep 1998 00:56:14 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from herring.nlsystems.com (herring.nlsystems.com [10.0.0.2]) by nlsystems.com (8.9.1/8.8.5) with SMTP id HAA07406; Mon, 21 Sep 1998 07:56:29 GMT Date: Mon, 21 Sep 1998 08:56:29 +0100 (BST) From: Doug Rabson To: Eivind Eklund cc: "Justin T. Gibbs" , hackers@FreeBSD.ORG Subject: Re: malloc()ing 64K physically contiguous buffer in kernel In-Reply-To: <19980921001637.40216@follo.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 21 Sep 1998, Eivind Eklund wrote: > On Sun, Sep 20, 1998 at 04:03:22PM -0600, Justin T. Gibbs wrote: > > In article <19980920212910.21253@follo.net> you wrote: > > > On Sun, Sep 20, 1998 at 01:45:24PM -0400, Bill Paul wrote: > > >> So: is there some way to allocate 64K of contiguous memory? Or even > > >> 8/16/32K? As long as I can hit one of the allowed buffer sizes I'll > > >> be happy, although I wanted 64K in order to reduce the likelyhood of > > >> receiver overruns. > > > > > > contigmalloc(). > > > > You should use bus_dma instead of contigmalloc, but I won't think > > badly of you until I've gotten off my duff and written the man > > pages for it. (bus_dma eventually uses contigmalloc to satisfy the > > request, but this may change (very likely on other platforms)). > > Speaking of this - what is the relationship between the bus_space > stuff you've brought in from NetBSD, and the bus framework dfr has > made for the alpha port? My bus framework code is more of a 'management' layer. It tracks driver registration, probes and attaches devices and constructs a nice device tree based on the runtime-probed bus topology. It copes with dynamic device detection and removal and dynamic driver replacement (you can't replace a statically linked driver though). The framework also allows drivers to define 'interfaces' which are collections of methods implemented in the driver. The traditional probe and attach methods are implemented in a standard 'device' interface. The advantage here is that it is trivial to extend a driver with new methods and still maintain binary compatibility with old drivers. Currently it stays far away from the hardware issues of bus_space and bus_dma. I will probably extend the 'bus' interface to allow parent bus, io and memory tags to be passed to child devices. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 951 1891 Fax: +44 181 381 1039 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message