Re: [PATCH] New phys_addr() syscall
Richard Gooch (Richard.Gooch@atnf.CSIRO.AU)
Mon, 20 Jul 1998 13:39:21 +1000
Jamie Lokier writes:
> > Alan Cox writes:
> > DMA doesnt honour the MMU write protect bits for copy on write, or for
> > page locking. Nor does it set the dirty bit on page table entries.
>
> And you can't get larger contiguous or aligned regions if the device
> needs them.
>
> BTW, I'm also doing userspace DMA things (similar to U-net). The driver
> I'm using does exactly this. It's mingled with a lot of other junk
> though and it's quite buggy, sorry I can't pass it on :-)
>
> I agree with what Alan says in another message, a driver that kmallocs
> and maps the memory to user space is a lot saner, not least because the
> driver has proper control over the type of memory (GFP_DMA if needed,
> for example, and none of the complications of normal user pages).
Just so I'm clear on this: I'm in no way saying that phys_addr(2)
combined with mlock(2) is the proper way to do this. I just wanted to
point out that you *could*, if you wanted. Sigh. Maybe I shouldn't
have mentioned that aspect at all.
Remember: I wrote this for my memory tester! If it allows you to do
other things, I have not problem with that. It may well be useful for
people who want to experiment with direct DMA. If that's the case,
it's a bonus, in my view.
Regards,
Richard....
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html