Date: Mon, 4 Sep 2017 16:53:08 -0400 From: Mark Johnston <markj@freebsd.org> To: Kevin Bowling <kevin.bowling@kev009.com> Cc: Johannes M Dieterich <jmd@freebsd.org>, freebsd-x11@freebsd.org, freebsd-current@freebsd.org Subject: Re: [RFC] future of drm1 in base Message-ID: <20170904205308.GB3048@bish> In-Reply-To: <CAK7dMtAYNQ2mYgJFOo37a%2BGO0%2BCt=LkcXLif3wPjch4y7tTTWw@mail.gmail.com> References: <20170903191908.GA1259@bish> <20170904193337.Horde.Wm3jEJaHwm_CuvGbAmSToz8@www.poelloepaeae.de> <CAK7dMtAYNQ2mYgJFOo37a%2BGO0%2BCt=LkcXLif3wPjch4y7tTTWw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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@freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-x11
> > To unsubscribe, send any mail to "freebsd-x11-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20170904205308.GB3048>