Hi,
On 12-06-17 13:44, Greg Kroah-Hartman wrote:
On Mon, Jun 12, 2017 at 12:07:41PM +0200, Hans de Goede wrote:
The most important thing is for the driver to be atomic if it's KMS only, and it would be good to have someone review that properly.
I believe it does not use the atomic APIs atm, so that would be one of the first things to fix then. Another question is if people (you and Daniel at least) can live with the non kernel-coding style shared files under the osindependent dir ?
Why not just spend a few days and fix up all of the kernel-style issues so it can be a "real" driver? It shouldn't take all that long, especially for someone with Linux kernel experience (hint, hint...)
The intention of the stuff below the osindepedent dir is for it to be shared 1:1 between vboxvideo driver implementations for different operating-systems. IIRC during the AMD DAL discussion Daniel indicated that some OS independent code was fine (and would be exempt from coding style rules) as long as it had a reasonable clean interface and was not re-implementing anything we already have in the kernel.
If Daniel's verdict is that this needs to be cleaned up, then sure I can easily do that. As mentioned I already did a lot of cleanup, including moving all the other files to the kernel coding-style and removing about 43000 lines of portability cruft / abstraction layers, what is left under the osindependent directory is just C-structure definitions and a few small plain C helper functions, which VirtualBox upstream would like to keep as is...
Only put stuff in staging for a good reason, and that reason can be "I don't know how to clean this stuff up", but I don't think that is the case here...
My main reason for submitting this for staging for now is that it needs to be moved to the atomic API which is non-trivial and will take a while, but if the drm subsys maintainers are willing to take it as is with the plan to convert it while it is already under drivers/gpu/drm that is even better :) Another reason is that I'm only somewhat familiar with the drm subsys, so this needs a good review which may result in other things which need fixing too.
Regards,
Hans