On 1/15/07, Arjan van de Ven <[email protected]> wrote:
> However, what I'd really like to do is to leave it to user space to
> allocate the memory as David describes. In the transmit case, user
> space allocates memory (malloc or mmap) and loads the payload into
> that buffer.
there is a lot of pain involved with doing things this way, it is a TON
better if YOU provide the memory via a custom mmap handler for a device
driver.
(there are a lot of security nightmares involved with the opposite
model, like the user can put any kind of memory there, even pci mmio
space)
OK, point taken. I don't have a strong preference for the opposite
model, it just seems elegant that you can let user space handle
allocation and pin and map the pages as needed. But you're right, it
certainly is easier to give safe memory to user space in the first
place rather than try to make sure user space isn't trying to trick
us.
> Then is does an ioctl() on the firewire control device
ioctls are evil ;) esp an "mmap me" ioctl
Ah, I'm not mmap'ing it from the ioctl, I do implement the mma file
operation for this. However, you have to do an ioctl before mapping
the device to configure the dma context.
Other than that what is the problem with ioctls, and more interesting,
what is the alternative? I don't expect (or want) a bunch of syscalls
to be added for this, so I don't really see what other mechanism I
should use for this.
> It's not too difficult from what I'm doing now, I'd just like to give
> user space more control over the buffers it uses for streaming (i.e.
> letting user space allocate them). What I'm missing here is: how do I
> actually pin a page in memory? I'm sure it's not too difficult, but I
> haven't yet figured it out and I'm sure somebody knows it off the top
> of his head.
again the best way is for you to provide an mmap method... you can then
fill in the pages and keep that in some sort of array; this is for
example also what the DRI/DRM layer does for textures etc...
That sounds a lot like what I have now (mmap method, array of pages)
so I'll just stick with that.
thanks,
Kristian
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
