[vbox-dev] [PATCH v2] staging: vboxvideo: Add vboxvideo to drivers/staging

[Hans de Goede]

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