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
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
