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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
