Re: [RFC] Deprecation and removal of the drm2 driver

On 5/21/18, Steve Kargl <sgk_at_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_at_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)
> _at__at_ -112,7 +112,9 _at__at_
>         ${_dpms} \
>         ${_dpt} \
>         ${_drm} \
> +.if ${MACHINE_ARCH} != amd64
>         ${_drm2} \
> +.endif
>         dummynet \
>         ${_ed} \
>         ${_efirt} \

I prefer something like this:

op_at_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
_at__at_ -23,6 +23,7 _at__at_ 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
>