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

On 5/21/18, Oliver Pinter <[email protected]> wrote:
> On 5/21/18, Steve Kargl <[email protected]> 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 <[email protected]> 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
>

Or make the function in this file smarter:
"./hw/xfree86/os-support/bsd/bsd_kmod.c"

#ifdef HAVE_XORG_CONFIG_H
#include <xorg-config.h>
#endif

#include <errno.h>
#include <fcntl.h>
#include <unistd.h>
#include <sys/param.h>
#include <sys/linker.h>

#include "xf86_OSproc.h"

/*
 * Load a FreeBSD kernel module.
 * This is used by the DRI/DRM to load a DRM kernel module when
 * the X server starts.  It could be used for other purposes in the future.
 * Input:
 *    modName - name of the kernel module (Ex: "tdfx")
 * Return:
 *    0 for failure, 1 for success
 */
int
xf86LoadKernelModule(const char *modName)
{
    if (kldload(modName) != -1)
        return 1;
    else
        return 0;
}

>
>>
>> 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
>>
>
_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-x11
To unsubscribe, send any mail to "[email protected]"