[PATCH v2] staging: vboxvideo: Add vboxvideo to drivers/staging
Michael Thayer
michael.thayer at oracle.com
Wed Jun 14 09:34:10 UTC 2017
Hello Sean,
13.06.2017 20:03, Sean Paul wrote:
[Discussion of vboxvideo driver clean-up.]
> First, thank you for your submission.
Thank you for your feedback.
[Discussion of the OS-independent code in the driver submission.]
> I took a quick skim through your driver, and there doesn't seem to be much
> secret sauce there that will be tough to keep up-to-date across platforms.
I have two particular concerns there: first if we add new functionality
(which we would do out of tree first) it will need porting over.
Acceleration support is the most likely candidate. And if someone does
make fixes to that part of the code in the kernel tree they will also
need porting over. I agree, that concern is probably overblown, and
best addressed by keeping that part of the code as close to our tree as
possible while still meeting kernel standards (hence my question as to
what that would be).
The second concern is not relevant to DRI, but it concerns our other
guest drivers (not the host one with the C++ in it Greg!) which Hans
also expressed interest in putting upstream after seeing how vboxvideo
fares. The OS-independent part is quite a bit larger and more volatile,
though it has thankfully stablised a lot. That concern is probably also
overblown, though I do wonder whether upstreaming those driver is the
best solution (that would be Hans's call though).
> One other concern I have is that I noticed there are a few functions
> declared/defined in the osindependent code that are never used outside of it, so
> we have dead code off the hop.
If the OS-independent part gets converted then they would be removed in
the process. Thank you for the reminder.
[...]
> IMO, in order to accept the driver in drm, the osindependent code needs to be
> stripped out and it needs to be converted to atomic. Whether you want to do
> this out of tree, or in staging is up to you. As Dave mentioned, people often
> overlook staging when making drm core changes, so you'll likely face the same
> moving target issues either way.
Conversion to Atomic would probably have to happen at some time or
another anyway. I have put that off (out-of-tree) so far because I was
tracking the AST driver as closely as possible as the simplest way of
picking up fixes, and because Dave, who wrote that, knows much more
about drm drivers than me.
[...]
Regards
Michael
--
Michael Thayer | VirtualBox engineer
ORACLE Deutschland B.V. & Co. KG | Werkstr. 24 | D-71384 Weinstadt
ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstraße 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603
Komplementärin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister
der Handelskammer Midden-Nederland, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
More information about the dri-devel
mailing list