> I am developing (together with Alessandro Rubini) a device driver (-module)
[...]
> Unlike most (all?) drivers the user should be able to allocate memory for
> DMA-purpose within his/her user-space via a malloc-like-call, as multiple
> DMA-buffers might be required, especially, if diffrent programs access the
> device simultaniously.
>
> Of cause, I'd prefer to do no changes to the actual kernel (no patching).
> I found out that nowmore kmalloc supports up to 128 kB-allocation
> of dma-able memory (GFP_DMA). Good! But how may I simply map this to
> user space? I want to write a library routine, that is called when the
> user wants to allocate memory and asks via the (character-)device-driver
> for the 1401 for the memory. The device-driver should then perform
> a kmalloc and map this data
> to user-space and return the address of it (if it succeeds). Of cause,
> the library routine could do the mapping via /dev/mem, but this would
> require to run supervisor-mode and would be much slower.
Yep. you would need supervisor-mode, but I don't see why that would be
slower, can you elaborate? A problem would be if you need to allocate
a dma buffer for each request and must remap all the time. But then even
a new syscall would have almost the same overhead.
What you could do to avoid supervisor-mode and use of /dev/mem and have more
control about what is mapped is just implement mmap for your newly written
device as well. That could be used to access seperate dma buffer for seperate
sessions (open files) on that device. You would just need
to adjust the processes paging tables to point to the kmalloc allocated
stuff with the correct access permission (do not just copy the kernel
space pagetable entries, these are supervisor mode only). Since the
kmalloced should be marked reserved in the page_map all paging routines will
keep there hands off that pages.
That sounds like the cleanest approach to me, no kernel patches would be
required for that (but you should read quite some parts of the kernel
mmanaging code and some x86 book about paging on the intel).
> *IF* I am right that no current driver performs such a task, I'd like
> to hear anybodys ideas onto how to perform this task. If I am wrong
> might anybody give me a hint to a driver doing such tasks?
I don't know any such driver too. However to see some weird things on
fiddling with processes paging tables you might take a look in my still
pre-pre-alpha work in progress framebuffer device driver snapshot at
tsx-11(and mirrors):pub/linux/ALPHA/scrdrv/fb* (modulo typos/wrong
capitalization)
> Georg
> Georg Zezschwitz - University of Hamburg -
> zezschwi@kogs7.informatik.uni-hamburg.de
> From: cjs <noone@nowhere.com>
> Subject: Re: Mapping Kernel-space to User-space
> To: zezschwi@kogs7.informatik.uni-hamburg.de (Georg v. Zezschwitz)
> Date: Fri, 23 Jun 1995 21:01:48 -0500 (CDT)
> Cc: linux-kernel@vger.rutgers.edu
[...cite of above mail...]
> Something to remember is that on the braindead intels that we all know and
> love, the DMA buffers need to be aligned on 4096 byte boundries and must
> reside in the first 16M or so of memory (except for certain unique chipsets
> and possibly anything made in the last year or so). In those latter cases
> there are supposed to be special flags you need to set to get the DMA transfers
> above the 16M marker.
Well.. he didn't tell how the card makes DMA. It could be some busmaster
(if it is that full featured with an own CPU), then these restrictions
usually not apply. (Of course there is a restriction on 16M for all ISA
bus cards).
Even then, I was told that kmalloc takes care of that when called with
proper parameters (GFP_DMA) the alignment is no problem too. When you alloc
more than fits on one page you'll get complete pages anyway. Even if not or
if 4096 alignment doesn't suffice you can just kmalloc some more memory
and place your dma buffer properly aligned into the bigger kmalloced area.
[...]
> Christopher
Michael.
(eowmob@exp-math.uni-essen.de or eowmob@pollux.exp-math.uni-essen.de
Please do not use my vm or de0hrz1a accounts anymore. In case of real
problems reaching me try mat42b@aixrs1.hrz.uni-essen.de instead.)