From owner-freebsd-arm@freebsd.org Wed Jul 18 14:42:04 2018 Return-Path: Delivered-To: freebsd-arm@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 0A492104CC88 for ; Wed, 18 Jul 2018 14:42:04 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1b.ore.mailhop.org (outbound1b.ore.mailhop.org [54.200.247.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2497D7D31A for ; Wed, 18 Jul 2018 14:42:02 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-RoutePath: aGlwcGll X-MHO-User: b9ce2edd-8a98-11e8-8837-614b7c574d04 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound1.ore.mailhop.org (Halon) with ESMTPSA id b9ce2edd-8a98-11e8-8837-614b7c574d04; Wed, 18 Jul 2018 14:42:00 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id w6IEfwJk056701; Wed, 18 Jul 2018 08:41:58 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1531924918.26036.71.camel@freebsd.org> Subject: Re: One last item: CNS1102 support removal From: Ian Lepore To: Warner Losh , "Rodney W. Grimes" Cc: "freebsd-arm@freebsd.org" Date: Wed, 18 Jul 2018 08:41:58 -0600 In-Reply-To: References: <201807181416.w6IEGToZ007635@pdx.rh.CN85.dnsmgr.net> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2018 14:42:04 -0000 On Wed, 2018-07-18 at 08:21 -0600, Warner Losh wrote: > On Wed, Jul 18, 2018 at 8:16 AM, Rodney W. Grimes < > freebsd-rwg@pdx.rh.cn85.dnsmgr.net> wrote: > > > > > > > > > There's one last item in arm land for 12 I'd like to remove: The Econa / > > > Cavium CN1102 support. > > > > > > It's literally received no updates since it was committed in 2010, apart > > > from others doing kernel sweeps. It's unmaintained. Strike one. > > > > > > Second, it will be the last armv4 port in the tree after I remove Atmel. > > We > > > > > > haven't had FreeBSD running on armv4 Atmel since FreeBSD 8. Strike two. > > > > > > Third, the original machines were released in 2005 or 2006. There's only > > > one known board, according to https://wikidevi.com/wiki/Cavium, and it > > came > > > > > > with only 16MB. So it's old and doesn't have much RAM. While barely > > > possible, in theory, to run FreeBSD/arm in 16MB, it's a huge PITA. Strike > > > three. > > > > > > Forth, I can find no mention of it in the archives or bug database. > > Strike > > > > > > four. > > > > > > I'm lead to the conclusion that this is no longer maintained, has no > > users, > > > > > > the hardware it was in has insufficient resources to run FreeBSD well and > > > these things are unlikely to change. Therefore, we should remove it. > > > > > > Comments? > > Again, I thought it was the plan to write and ratify a deprecation > > policy then start to purge the tree per the converstations at > > BSDCan 2018.  It seems your going the other way around. > > > No, I'm using the ARM removal to write the draft because there's > significant agreement in the arm community, and a strong desire to purge. > The community is also smaller, and it's easier to get consensus. Plus, this > code is almost broken and won't work: It's been 4 major revisions since we > had working armv4, so I'm rushing to get this done before 12. > > > > > > Though yes, these are clear cases that probably should be purged, > > they are also excelent examples to test the policy with and see > > how well it works. > > > Well, that's why I'm doing a few easy cases: to provide case studies for > the draft. Most of the other removal for x86 stuff was, at BSDcan, agreed > we'd do the purge after 12 branched. > > > > > > What is the status of the deprecation policy draft? > > > Mostly done. I should publish it next week on arch@ for discussion. > > Warner Also, to me this stuff seems different than deprecation. You deprecate something when you foresee its impending doom, either because it's being replaced with something newer, or because other changes are going to drive things to a point where ongoing support becomes impossible. So you begin a process of informing existing users of an impending deletion or lack of support so that they can takes steps to prepare. The situation where you have no users to inform, or where something is noticed to have been broken already for some time (which is really another way of saying it has no active users), that's not a situation where a deprecation notice provides value to anyone. The only thing a formal process does in that case is slow down the work that obviously needs to be done. -- Ian