[lkml]   [1999]   [Aug]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [bigmem-patch] 4GB with Linux on IA32
>On Tue, 17 Aug 1999, Linus Torvalds wrote:
>> The code in question cannot be "fixed". It's doing something wrong in the
>> first place,
>To expand on the above:
> If you write a driver and you want to give direct DMA access to some
>program, the way to do it is NOT by using some magic ioctl number and
>doing stupid things like some drivers do (ie notably bttv).
>The way to do it is to just be up-front about the fact that the user
>process wants direct access to the buffers that the IO is done from, and
>use an explicit mmap() on the file descriptor. The driver can then
>allocate a contiguous chunk of memory of the right type, and with the
>right restrictions, and then let the nopage() function page it into the
>user process space.

I've got a driver for a native Virtual Interface Architecture device,
which is this thing Intel has been flogging for a while. The API
allows user processes to register arbitrary virtual address ranges for
DMA; the driver then pins the pages and loads a map on the adapter
with virtual->user translations so that the user process can initiate
DMA using virtual addresses.

With a bit of work I think my driver might be bigmem-safe, as although
it walks the page table, it only translates to DMA-able bus addresses,
and never to kernel virtual memory addresses. The mmap() solution
doesn't work here, at least in a way that conforms with the API we're
trying to implement, because it doesn't allow the application to
register its own buffers. Physical contiguousness isn't an issue,
because the hardware can do per-page scatter/gather.

One approach to this issue is to just declare VI and things like it an
abomination against all well-designed I/O architectures, and forget
about it. However, it's quite possible that translating user virtual
addresses to bus addresses and locking the pages would be useful in
other cases, like zero-copy transport protocols and possibly in future
async I/O, although in those cases the mapping&locking would only last
for the duration of a single I/O operation.

Peter Desnoyers (978) 461-0402 x228
Giganet Inc. (978) 461-0430 (fax)
2352 Main St., Concord, MA 01742

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:53    [W:0.450 / U:0.084 seconds]
©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site