For those wondering at what's going on with this, I've shared the following with the developers@ mailing list. I thought I'd share it here to fight the misinformation that's swirling about. We don't have all the answers yet, and I'm working on it with others in the community to get the best outcome possible. We have to look at all the options and consider all the angles because this is a complicated and nuanced problems and 'simple' solutions are apt to create more problems than they solve.
> https://reviews.freebsd.org/D16894 is the next step. I plan on committing > it later today or tomorrow barring big issues with it (it's already been > approved by members of the graphics working community and a member of > release engineering). > > It puts a big ugly deprecation notice and makes the drm modules dependent > on a build option. > > But it's not the last step. > > The only real issue we have is that we have two modules name the same: > i915kms.ko and radeonkmw.ko. There's also drm.ko, but versioning seems to > save us from that being an issue with the latest kernel and maybe loader (I > need to test that last detail, and fix what I think might be an issue > there). > > There's multiple ways you can fix this. One would be to turn off the build > on amd64 of these modules. This breaks old users, but not in a horrible way > (they can just turn it on and rebuild, or possibly install the port). > Second would be to fix the boot loader to have per-module paths (or rather > put the kernel path last) as well as doing similar hacks to the kernel > loader. This is fragile, but seems to have some promise. We can't just > change the module path for all modules at this late date, however. So this > solution, if it were working perfectly, could remove all POLA, but we risk > breaking other things. Third, there's been suggestion of having different > module dependencies such that you'd get the right driver no matter whether > or not you have the port installed, though I've not had a chance to see if > the kernel module version code might be able to load the right module > always, but we'd also need to change the boot loader since I don't think > the right logic is there. > > Finding the right solution is a bit tricky because there's so many > different scenarios to consider and test. The immediate next step is being > investigated to find the best path forward in a thoughtful, methodical way. > If you'd like to help, please contact me privately. I'm not sure a > discussion on developers would be fruitful: I'm providing detail here in > the interests of transparency, not because I'm looking for help, per se. > Before I do a next step, I'll circulate my preliminary conclusion along > with a write up for each of these possible solutions outlining the pros and > cons of each so we have it well documented for future reference. > > Longer term, after the freeze, the plan is to remove all the drm drivers, > the drm code and the drm module. We'll also remove the drm2 module builds, > intel and radeon drivers and firmware. We'll likely move what's left of > sys/dev/drm2 to sys/arm/dev/drm2 and hack the *files* files for it to build > in the new place (I have a review in phab to do this, the effort is almost > trivial). Arm is hard to share linux graphics drivers with, as documented > in https://gist.github.com/strejda/c98e513c2ec1d2e23005bb66a7bc6399, so > for the moment we need to stay with drm2 base for its graphics drivers. > That will develop independently of the other platforms, which can share > either drm-stable-kmod, drm-devel-kmod or drm-legacy-kmod ports at the path > forward. These details are in draft form, but are not likely to change a > huge amount. All the people / groups involved that I've spoken with are > on-board for this long-term plan. > > Also longer term, there's many social issues we need to solve. But I don't > want to derail getting the technical things done with them at the moment > playing the blame game. Suffice to say, after looking at things in detail, > I believe everybody from core on down to individual developers deserves > some blame for how we got here, and hyperbolic narratives that paint one > person or faction as evil are not only wrong, they are also part of the > problem. I promise I'll write up something with more specific detail once > we're through the technical phase of the drm work. > Warner _______________________________________________ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
