Re: [RFC] future of drm1 in base

On Mon, Sep 04, 2017 at 01:28:38PM -0700, Kevin Bowling wrote:
> I wasn't subscribed to -x11 earlier but do want to add some commentary
> to this thread.
> 
> The language describing these drivers in upstream is not at all
> ambiguous WRT to how bad these are and Linux distributions have
> dropped them:
> 
> <cut>
> menuconfig DRM_LEGACY
> bool "Enable legacy drivers (DANGEROUS)"
> depends on DRM && MMU
> select DRM_VM
> help
>  Enable legacy DRI1 drivers. Those drivers expose unsafe and dangerous
>  APIs to user-space, which can be used to circumvent access
>  restrictions and other security measures. For backwards compatibility
>  those drivers are still available, but their use is highly
>  inadvisable and might harm your system.
> 
>  You are recommended to use the safe modeset-only drivers instead, and
>  perform 3D emulation in user-space.
> 
>  Unless you have strong reasons to go rogue, say "N".
> <cut>
> 
> There seems to be some kind of misunderstanding that removing these
> drivers is taking something away from users.  I disagree.  It does
> _not_ deorbit HW support.  We'd be giving users a supportable and
> secure experience by dropping them.  For 2d desktop it is likely that
> a framebuffer is fast(er) as David states.  On any reasonable CPU 3d
> (like the server models people pointed out) may even be faster using
> llvmpipe.

I don't disagree in principle with removing the drivers, but if it's
done it should be done for a good reason. I addressed the issue of the
KLD name collision below, but security concerns are a more valid
motivation for removing them. OTOH, the legacy drivers are not included
in GENERIC kernels, so we're effectively doing the same thing as
upstream Linux by making them opt-in by default, albeit without the
scary warning.

> 
> Regards,
> 
> On Mon, Sep 4, 2017 at 12:33 PM, Johannes M Dieterich <jmd_at_freebsd.org> wrote:
> >
> >
> >
> > Mark Johnston – Sun., 3. September 2017 15:19
> >> On Sat, Sep 02, 2017 at 10:02:57PM -0400, Johannes M Dieterich wrote:
> >> > Dear current/x11,
> >> >
> >> > please CC me on responses.
> >> >
> >> > I am writing you on behalf of the FreeBSDDesktop team concerning the
> >> > future of drm1 in base.
> >> >
> >> > drm1 in base supports the following GPUs:
> >> > * 3dfx Banshee/Voodoo3+ (tdfx)
> >> > * ATI Rage 128 (r128)
> >> > * ATI Rage Pro (mach64)
> >> > * Matrox G200/G400 (mga)
> >> > * Savage3D/MX/IX, Savage4, SuperSavage, Twister, ProSavage[DDR] (savage)
> >> > * SIS 300/630/540 and XGI V3XE/V5/V8 (sis)
> >> > * VIA Unichrome / Pro (via)
> >> >
> >> > Since their original introduction up to 2010 these drivers have mostly
> >> > been maintained as part of larger cleanups. The newest hardware drm1
> >> > supports dates from 2004, if I am not mistaken, and most of the
> >> > hardware is AGP-based.
> >> >
> >> > With the introduction of graphics/drm-next-kmod which brings its own
> >> > drm.ko following the Linux notation, we are facing collisions between
> >> > these old drivers' drm.ko and the newer one.
> >>
> >> I don't think this is a real problem. The reason one currently needs to
> >> manually load the drm-next drm.ko (rather than just kldloading a driver
> >> and having it pick up the right drm.ko automatically) is that our drm.ko
> >> defines the same module ("drmn") as drm2.ko in the base system. So upon
> >> attempting to load a drm-next driver, the kernel uses the linker hints
> >> to load drm2.ko, which is incorrect. However, this can be addressed by
> >> simply bumping the drmn version in the port and modifying the drivers
> >> accordingly. I've submitted a 4-line PR which does exactly that. After
> >> that change, we can modify the pkg-message to omit drm.ko from the
> >> kld_list value. As a result, the name of our DRM module doesn't matter
> >> since users don't need to specify it, so the collision with drm1 isn't a
> >> problem.
> >>
> >> > We would like to hear if anybody still runs CURRENT on machines housing
> >> > the above GPUs and relies on drm1.
> >> >
> >> > If there are still a significant number of people running CURRENT on
> >> > this hardware in production, we would be willing to make a
> >> > graphics/drm-legacy-kmod port.
> >>
> >> With the PR I mentioned above, I think it's a non-issue to keep drm1 in
> >> the base system. Since there appear to be at least some users of those
> >> drivers, I really think it would be preferable to avoid removing them
> >> unless it's absolutely necessary.
> > Your proposed solution does work, thanks for providing it! Let's move this conversation to a later point in time then.
> >
> > Johannes
> > _______________________________________________
> > freebsd-x11_at_freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-x11
> > To unsubscribe, send any mail to "freebsd-x11-unsubscribe_at_freebsd.org"