Date: Mon, 21 May 2018 20:25:41 +0200 From: Oliver Pinter <oliver.pinter@hardenedbsd.org> To: sgk@troutmask.apl.washington.edu Cc: Pete Wright <pete@nomadlogic.org>, 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> Subject: Re: [RFC] Deprecation and removal of the drm2 driver Message-ID: <CAPQ4ffujnxUZfYsRXjACoQTQyWdE3WkKYcqeuGVp_797UO68rw@mail.gmail.com> In-Reply-To: <20180521181057.GA86707@troutmask.apl.washington.edu> 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> <20180521181057.GA86707@troutmask.apl.washington.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On 5/21/18, Steve Kargl <sgk@troutmask.apl.washington.edu> wrote:
> 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} \
I prefer something like this:
op@opn src# git diff
diff --git a/sys/amd64/conf/GENERIC b/sys/amd64/conf/GENERIC
index 195b66daab51..034e2f8126fd 100644
--- a/sys/amd64/conf/GENERIC
+++ b/sys/amd64/conf/GENERIC
@@ -23,6 +23,7 @@ ident GENERIC
makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols
makeoptions WITH_CTF=1 # Run ctfconvert(1) for DTrace support
+makeoptions WITHOUT_MODULES="drm drm2" # by default disable the
building of DRM* for GENERIC
options SCHED_ULE # ULE scheduler
options PREEMPTION # Enable kernel thread preemption
>
> 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?CAPQ4ffujnxUZfYsRXjACoQTQyWdE3WkKYcqeuGVp_797UO68rw>