On Sun, 13 Dec 1998, Alan Cox wrote:
> > (since it's video-capture, mlock() should not be much of an issue, the
> > card is a controlled resource anyway. If in the future we will have video
>
> His torvaldsness rejected a patch that made mlock callable from inside drivers
> to do this sort of stuff. So thats not a possibility.
Sure it is.
You just don't do it from the driver.
Alan, just sit down and think for a moment. You're talking about a _very_
specialized use: video streaming (whether it's incoming or outgoing is
immaterial, but basically it's the only thing right now that generates
that kind of data for a "real user" kind of application in a desktop
environment).
What that tells me is simple: it's so specialized that the kernel
shouldn't do more than give it minimal support. Remember my arguments
about X11 and letting most of the work be done in user level? It's
basically the same issue.
In short, if you're doing video capture, then you might as well bother to
write a program that allocates the 2MB or whatever of the frame buffer,
and locks it down itself, and THEN it tells the frame buffer driver that
"Hey, stupid, here's some memory, it's all there, and it's private and
locked down, go to town with it".
Do you now understand why his torvaldsness tells you not to do it in the
driver? A driver is not a memory management device. When I make changes to
how the memory management works, I pretty much require that no driver will
really care. I can live with drivers looking up some mapping that they
know is static and doesn't go away (see above), but having drivers do
mmap() etc? No thank you, that's what we have memory management code to
do.
Linus
-
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.tux.org/lkml/