>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 -- _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel