Date: Mon, 21 May 2018 20:40:50 +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: <CAPQ4ffv%2Ba84yvzUi52aEVy13j-=Vgs6V%2Bam3CamUBDomQEvXHA@mail.gmail.com> In-Reply-To: <CAPQ4ffujnxUZfYsRXjACoQTQyWdE3WkKYcqeuGVp_797UO68rw@mail.gmail.com> 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> <CAPQ4ffujnxUZfYsRXjACoQTQyWdE3WkKYcqeuGVp_797UO68rw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 5/21/18, Oliver Pinter <oliver.pinter@hardenedbsd.org> wrote:
> 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
>
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
>>
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAPQ4ffv%2Ba84yvzUi52aEVy13j-=Vgs6V%2Bam3CamUBDomQEvXHA>