Date: Mon, 21 May 2018 11:10:57 -0700 From: Steve Kargl <sgk@troutmask.apl.washington.edu> To: Pete Wright <pete@nomadlogic.org> Cc: Rozhuk Ivan <rozhuk.im@gmail.com>, Niclas Zeising <zeising+freebsd@daemonic.se>, FreeBSD X11 mailing list <freebsd-x11@freebsd.org>, Current FreeBSD <freebsd-current@freebsd.org>, Warner Losh <imp@bsdimp.com>, Oliver Pinter <oliver.pinter@hardenedbsd.org> Subject: Re: [RFC] Deprecation and removal of the drm2 driver Message-ID: <20180521181057.GA86707@troutmask.apl.washington.edu> In-Reply-To: <a6a41f91-9fcf-b21d-2460-018118b5756e@nomadlogic.org> References: <3a5edc5c-3caa-830b-4bd9-53ff52feb8a7@freebsd.org> <CAPS9%2BSv6SDWkbrEZruM4g2%2BOfw4ksvbtiMF=Q_towrMtJrgt1w@mail.gmail.com> <20180518193009.GA88432@troutmask.apl.washington.edu> <CANCZdfoMrFCyPteChSWgfYRY-uOyazzR0ZbYvp_OVmXRTe-Hqw@mail.gmail.com> <20180520164011.GA6276@troutmask.apl.washington.edu> <88843bfb-34de-382c-9409-83f9ad54c8c4@daemonic.se> <CAPQ4ffvd1da%2BiMXtPfz%2BxETqPZwgmNoBa5yZMSF26qPMkSD2qQ@mail.gmail.com> <20180521024050.0857a787@gmail.com> <20180521170728.GA14025@troutmask.apl.washington.edu> <a6a41f91-9fcf-b21d-2460-018118b5756e@nomadlogic.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, May 21, 2018 at 10:29:54AM -0700, Pete Wright wrote:
>
> On 05/21/2018 10:07, Steve Kargl wrote:
> > On Mon, May 21, 2018 at 02:40:50AM +0300, Rozhuk Ivan wrote:
> >> On Sun, 20 May 2018 21:10:28 +0200
> >> Oliver Pinter <oliver.pinter@hardenedbsd.org> wrote:
> >>
> >>>> One of the reasons for the deprecation and removal of the drm2 bits
> >>>> is that they prevent us from automatically loading the
> >>>> drm-next/stable-kmod kernel modules, since the two collide.
> >>>> Regards
> >>>
> >>> Then it wold be better to resolve this problem, rather then removing a
> >>> working solution. What's about module versioning what in other cases
> >>> works?
> >>>
> >> May be just move old drm2 to ports?
> > Why? "If it isn't broken, why fix it?"
> >
> > The conflict affects x86_64-*-freebsd aka amd64. The
> > conflict does not affect any other architecture. The
> > Makefile infrastructure can use MACHINE_ARCH to exclude
> > drm2 from build of amd64.
> >
> > I don't use netgraph or any of the if_*.ko modules.
> > Can we put all of that into ports? I don't use any
> > scsi controllers, so those can go too. Why make it
> > insanely fun for users to configure a FreeBSD system.
> to play devils advocate - why include a kernel module that causes
> conflicts for a vast majority of the laptop devices that you can
> purchase today (as well as for the foreseeable future), while forcing
> the up to date and actively developed driver to not work out of the box?
Poor advocacy. I stated old drm2 can be excluded by the
Makefile infrastructure and I've already provided a barebones
patch.
Index: sys/modules/Makefile
===================================================================
--- sys/modules/Makefile (revision 333609)
+++ sys/modules/Makefile (working copy)
@@ -112,7 +112,9 @@
${_dpms} \
${_dpt} \
${_drm} \
+.if ${MACHINE_ARCH} != amd64
${_drm2} \
+.endif
dummynet \
${_ed} \
${_efirt} \
Those interested in killing old drm2 on amd64 can add the
requisite .if ... .endif to remove obsolscent *.ko.
> IMHO it is issues like this (having out of date code that supports some
> edge cases) which makes it harder for developers to dog-food the actual
> OS they are developing on.
You're talking to 1 of the 3 contributors that has tried over
the last 2 decades to improve libm (both its quality and
conformance to standards). The development and testing is
done on my old i386 laptop (which happily uses drm2), my
amd64 systems, and at one time sparc64 (flame.freebsd.org).
So, yeah, i386 and sparc64 allowed me to dog-food my code.
BTW, there are uncountable many integers. How about avoiding
the conflict by using, say, '3' as in drm3.
--
Steve
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20180521181057.GA86707>