On 5/21/18, Steve Kargl <s...@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.pin...@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
>
_______________________________________________
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
