Hmm, this proposal still doesn't satisfy my needs for the frame grabber
driver I will have to write.

The problem is, that it doesn't support the allocation of physical memory
(without the help of a daemon process) to dma data into/out of, of which
only some part is mapped to user memory.

As an example let me give a short description of the relevant machinery in
the aforementioned frame grabber:

The grabber can only grab into memory that looks contiguous on the pci bus.
On machines like the i386 this means that the region to grab into has to be
really contiguous in main memory.

Now this region is pretty large (depending on the resolution and color depth
up to ~1.7 MB per frame to grab, and my customer has two of these grabbers
in his machine and wants to at least grab with double buffering :-)), so one
wants to avoid mapping this into kernel virtual space (especially since the
i386 has kernel virtual memory limitations).

If for some reason an application program wants to only map part of this area,
I need to have a physical memory area that isn't mapped into any virtual memory
area in its entirety (if I don't resort to some daemon process that does the
mapping).

Another problem with the proposal in this context is that it'd at least be a
bit complicated to map the grabber's buffer into more than one process' memory.

I suspect that what I'm looking for is a way to allocate a dma-able area of
memory without mapping it into any address space.  The mechanism to map all
or part of this memory to user space would be separate from this (and is
probably quite easy, similar to the way that frame buffers are mapped into
user memory).  Optionally the allocation function can map the area into
kernel virtual memory (if this is really required).  And I'd probably encode
the fact that the memory isn't mapped into any address space by extending the
possible segment spaces with UIO_PHYSSPACE or some such.

Am I completely babbling nonsense here?
--
ws@TooLs.DE     (Wolfgang Solfrank, TooLs GmbH) 	+49-228-985800