From owner-freebsd-current@freebsd.org Wed May 23 01:29:24 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 73845EE8EEE for ; Wed, 23 May 2018 01:29:24 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0D8AB714A8 for ; Wed, 23 May 2018 01:29:23 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from zeppelin.tachypleus.net (cpe-75-82-218-62.socal.res.rr.com [75.82.218.62]) (authenticated bits=0) by d.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id w4N1TFKX008843 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Tue, 22 May 2018 18:29:15 -0700 Subject: Re: [RFC] Deprecation and removal of the drm2 driver To: freebsd-current@freebsd.org References: <201805222212.w4MMCdA9031937@pdx.rh.CN85.dnsmgr.net> From: Nathan Whitehorn Message-ID: <3e261ac2-4be0-7105-277a-92cf63511cb4@freebsd.org> Date: Tue, 22 May 2018 21:29:14 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <201805222212.w4MMCdA9031937@pdx.rh.CN85.dnsmgr.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Sonic-CAuth: UmFuZG9tSVbk+Lb7mpskeO26/bg7apa4WRnmgz9Tvex6fzes0CVqFrh46roLMFxwwG81g/gx54h3uG1xIg8XfWWiSLCLPooodowIYsrPHtY= X-Sonic-ID: C;/kRCtChe6BGhEMURjESG/g== M;sDGotChe6BGhEMURjESG/g== X-Spam-Flag: No X-Sonic-Spam-Details: 0.0/5.0 by cerberusd X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2018 01:29:24 -0000 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