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

On 05/22/18 18:12, Rodney W. Grimes wrote:
>>>
>>> it makes me giggle that people still think non-amd64 is "legacy".
>>>
>>> i386 is alive and well - new chips are being fabbed based on the 586
>>> design with pci-e slots; not to mention things like the Talos and
>>> AmigaOne for PowerPC.
> Yes, some how we need to shake off the idea that all the world
> is going to be 64 bit, and stop talking about EOL for 32 bit
> x86,   IMHO that would be a serious mistake.  For one any VM
> that does not need >4G of address space is a waste to run
> in 64 bit mode.
>
>> DRM2 doesn't support anything later than mid-Haswell. The chips in
>> question all pre-date 2007. Users of low-volume hardware on chips from
> Um, haswell announced in 2011, started shipping in mid 2013, and last
> product started to ship in 2015, so if "mid-haswell" is the supported
> chip arrena that would be pre date 2012?
>
> Also as the Moore's law curve flattens expect the life of these
> older, but not so old, machines to live quiet some time.  I
> believe we are talking sandy bridge and earlier?  If that is
> corret Sandy bridge is still a very viable system.
>
>> that period are welcome to continue to sustain themselves on the drm2
>> port just as the other 95+% of the user base will use what is now
>> referred to as drm-next. Even by powerpc maintainers' admission DRM2
>> also only barely works there. I've promised Justin that I'll make
>> drm-next work on Talos once POWER9 support is solid enough.
> I think the original RFC has been answer, yes there are people still
> using DRM2, and they wish to continue to use it into the 12.x time
> frame.
>
> Lets find a technically agreeable solution to that, and move forward.
>
> I am concerned about just disabling the compile on amd64,
> that typically leads to bit rot of the i386 code.
>
> I am concerned about just shoving it out to ports, as that makes
> it rot even faster.
>
> I am still very concerned that our in base i9xx code is like 4
> years old and everyone is told to go to kmod-next from ports
> as well.
>
> No, I do not have a solution, but I have not tried hard to find
> one.  I am sure if we try hard to find one it can be done.
>
> Regards,

The real question in this thread is, I think: Do we want to co-version 
the drm kernel modules with kernel/OS releases or with the graphics 
drivers that use them (which are in ports)? I use the base modules (on 
2014-era amd64 hardware), but would be perfectly happy with modules in 
ports and it seems like there is a compelling argument for co-versioning 
the things in x11-drivers with the kernel modules.

I would like to make a proposal here:
- Rename drm-next to drm-kmod
- Move sys/dev/drm2 to a new port drm-kmod-legacy
- Have one of the two, by default drm-kmod (amd64) or drm-kmod-legacy 
(i386), pulled in as a dependency by the relevant X11 drivers
- Garbage-collect dev/drm, which supports 3DFX and Rage 128 and such 
archaic things

I think this keeps the user experience intact and lets the graphics 
developers update in the way that works best for them.
-Nathan