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

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?

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.  Having things work on modern hardware by 
default seems like a great way to get more people on the platform 
testing and bugfixing things.

The suggestion seems like a pretty good middle ground, people with older 
devices will still have workable code while also making it easier to 
continue to follow the state of the art in terms of hardware support.

-pete

-- 
Pete Wright
pete_at_nomadlogic.org
_at_nomadlogicLA