Date: Thu, 12 Apr 2007 13:03:07 +1000 From: Alan Garfield <alan@fromorbit.com> To: Craig Boston <craig@tobuj.gank.org> Cc: hackers@freebsd.org Subject: Re: Resources and ACPI Message-ID: <1176346987.4175.2.camel@hiro.auspc.com.au> In-Reply-To: <20070411164050.GD60020@nowhere> References: <200704110951.l3B9p4hT024402@sana.init-main.com> <461CCB3D.1090402@fromorbit.com> <20070411140214.GA60020@nowhere> <1176302227.5057.12.camel@hiro.auspc.com.au> <20070411153703.GC60020@nowhere> <1176308551.5949.7.camel@hiro.auspc.com.au> <20070411164050.GD60020@nowhere>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 2007-04-11 at 11:40 -0500, Craig Boston wrote: > Looking back at the thread I see that you're porting a Linux driver, > that explains a lot of the confusion. It's been a while since I've > worked with the Linux kernel in depth, but I seem to remember that a lot > of drivers (especially machine-specific ones) would get the resource > directly, e.g. IO port base address, and then do stuff like > > outb(base_addr + offset, value); > value = inb(base_addr + offset); > > or write to mapped memory directly by constructing a pointer to the > address. Indeed mapped memory is how this is driver is written. > While doing this is possible in FreeBSD, it's discouraged as the > bus_space API tends to make for cleaner code and is also more portable. > On architectures with peculiar alignment requirements, or other > restrictions (DMA buffers having to be below a particular address comes > to mind, or bounce buffers for PAE), the OS will take care of most of > the nitty gritty details for you and allow the driver to contain > higher-level code. Yes bus_space seems much nicer, and very useful I'm sure for platform independence. Cheers, Alan.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1176346987.4175.2.camel>