Subject: Re: File I/O in hardware device driver
To: Steven Grunza <email@example.com>
From: Eduardo Horvath <firstname.lastname@example.org>
Date: 07/28/2000 11:15:12
What ARE you doing?
On Fri, 28 Jul 2000, Steven Grunza wrote:
> Two possible problems with my driver just occurred to me:
> 1) Doing file IO from a hardware device driver might not be a good
> idea. Is it legal for an IOCTL to my driver to provide the name of a
> file which my driver then opens with your typical open() or fopen() type
> of call?
That is not a good thing to do. A driver should not be opening
files. That's for applications to do.
> 2) Allocating 600+KB of physical memory (wired to prevent swapping it
> out) may be a bad idea. How much is available? Is it configurable?
> The application software requires 128MB in a system so there should be
> enough physical memory in the box but can a malloc() in the kernel grab
> a 600+KB chunk of contiguous, non-swappable memory?
600+KB of kernel memory is a rather large chunk. Virtually contiguous or
physically contiguous? Virtually contiguous is relatively
easy. Physically contiguous is not.
> 2a) How should I allocate this memory? Would it be a MALLOC(9) call or
> some kind of a uvm_pagealloc(9) call? This code will need to run on any
> system with a PCI bus, i386 and SPARC for certain. Possibly others....
You should use bus_dmamem_alloc(9). See bus_dma(9). You should also be
using the bus_space interfaces. See bus_space(9).