RE: [Linux-fbdev-devel] Current discussion about the future of free software graphics

It does, or the ioctl must verify the register data, which could require
about the same amount of code as computing it in the kernel in the first
place (possibly even more; the problem changes from computing a valid
combination of register values for a specific requested mode to limiting
the huge number of register value combinations to those that don't lock
up the chip or worse). I've pointed this out several times before, but
nobody has presented a solution yet. Will the userspace code live in a
daemon that runs as root? Or will only privileged processes be allowed
to change display properties?

I am in agreement with Michel on this point.
There is a privilege problem.
Either you trust the data coming from user-space to kernel-space
implicitly which means the user-space process now must be privileged,
or you don't trust user-space and you have to re-validate the data coming
into the kernel.
The former doesn't buy you much. Now you have another root running deamon
floating around to be a security problem.
The latter's protocol and re-validation is difficult to the point of being
a complete waste of effort.

I have conceded that I am fine with a user-space mode setting API
as long as there is no imposed user/kernel split. For those who's chips
would require too much code to revalidate, they can just put the whole
mode setting in the kernel. I think we will discover that many of the
more advanced drivers will end up taking this route.

In the end I think this design is more complicated than is necessary. The
end goal should be to minimize privileged code, not just kernel code. When
you go with a split design you are forcing more privileged code than if
all the code lived in the same place.



-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to 
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3