On Wed, Jun 14, 2017 at 11:34:10AM +0200, Michael Thayer wrote: > 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). Once the code is upstream, it's going to be difficult to motivate developers to keep the driver close to your downstream version. If I'm working on feature X which touches your driver, I'm not going to figure out how your internal version works so that I might ease your pain. I don't mean that to be rude, just realistic. Sean > > 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 -- Sean Paul, Software Engineer, Google / Chromium OS _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
