Brian S. Julin wrote:
> Well, there are benefits to being able to mlock memory, in that
> the driver doesn't have to be the one to track ownership of locked-up
> pages, plus that way the driver cannot be used to circumvent ulimits.
well, I don't see taking away ownership from drivers as an advantage.
It basically means that your application can corrupt the system, which
is what the separation between kernel and application space wants to
prevent in the first place.
> Still, you have to tell the driver about the memory in
> any case if you want the driver to use it from kernel space, such
> that the driver can find the kernelspace address, but at least
> the driver isn't duplicating the functions of the kernel mm if the
> userspace app can do the initial aquisition/freeing.
>
> Anyway, we do not necessarily _always_ want to use a "real ram" allocation
> with a graphics driver; could be useful to have a page that you
> doodle on with no possibility of swap device delay, though I imagine
> that will be of limited utility.
yeah, right. But that you can get with a sufficiently rich system API,
too (such as mmap and family). That's what I was aiming at with the
reference to a new console API...
Regards,
Stefan
