Hello Hans, Continuing this in a new thread without all the other recipients.
14.06.2017 17:03, Hans de Goede wrote: > Hi, > > On 14-06-17 15:40, Michael Thayer wrote: >> Hello Hans, >> >> 14.06.2017 15:30, Hans de Goede wrote: >> [Discussion of vboxvideo and vboxguest driver clean-up.] >>> As I already mentioned in previous mails on this, for the vboxguest >>> driver >>> my plan is to simply do a fork and remove anything related to the >>> portability. It currently weighs in at 100000+ lines of code which is >>> a bit >>> much for what it does I believe I will be able to get a Linux only >>> version >>> of it down to a small fraction of that and the result will be a much >>> cleaner >>> and better driver. >>> >>> FWIW I've already stared looking into cleaning up the vboxguest >>> driver and >>> my first target is to remove all dependencies on the r0drv code. I have been thinking about this again. As I said before, this is your decision to make, but I wonder whether getting vboxguest into the upstream kernel is the most sensible approach to take, and for that matter the best use of your time. I do realise that Red Hat have a policy of trying to keep their kernels (the Fedora ones at least) as close to upstream as possible, but I presume that exceptions are possible. It seems to me that you are likely to expend quite a bit of effort integrating our changes into an in-kernel version of vboxguest with the result that most distributions will still end up with an outdated version which needs replacing by our one. I have been discussing Additions packaging in Debian in a different thread on vbox-dev with Gianfranco Costamagna, who maintains the Debian and Ubuntu Additions packages. It seems to me that focussing on distributions (in your case Fedora and Red Hat EL) having up-to-date Additions versions would be a better time investment than putting vboxguest in the kernel, and time spent rewriting it to reduce size spent looking for ways to clean up our version (for me that is upstream). While that will not be as easy as with vboxvideo, which was written from the start with a view to keeping dependencies on the rest of VirtualBox low, there are probably still low-hanging fruit: vboxguest is not something that one person has consistently developed, but rather something that lots of people on the team have worked on briefly, often as part of a larger set of work. And of course, we would be open to reducing dependencies where possible (possibly also something like the compatibility header we did for vboxvideo), and towards making the Additions easier to package. Regarding keeping distributions up-to-date with Additions, it seems to me that the kernels move so fast in in-support versions of Fedora that just building the most recent version of the kernel modules whenever the kernel is updated (possibly even as part of the kernel package) would make sense. EL on the other hand is slower moving and has its regularly updated module ABI, so a separate Additions module package, updated when we release a new version or when the kernel ABI is bumped might be appropriate. So as I said, just my thoughts - sorry for the length! - but do think whether it might make sense for you. Regards Michael >> Moving off-topic, but please let me know if you set up a git repository >> for it as you did for vboxvideo. > > Will do. > >> Do you have plans (applies to >> vboxvideo too) for how to merge changes to our code into the cleaned-up >> code? > > The git repo will have an "upstream" branch which will contain the > vboxguest > dir from the tarbal created by the src/VBox/Additions/linux/export_modules > script. My plan is to sync that branch regularly by coping over a fresh > copy of that dir, then commit that as a commit on top of the previous > sync and look at the git diff to see what changed. Then where necessary > I will port over the changes to the cleaned up version. > >>Of course, I am open to patches or suggestions as to how to >> simplify the code in our repository as long as they do not affect other >> platforms (vboxguest builds and runs for five different operating system >> kernels). >> >> Regards >> Michael >> >>> Regards, >>> >>> Hans >> -- 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 _______________________________________________ vbox-dev mailing list [email protected] https://www.virtualbox.org/mailman/listinfo/vbox-dev
