Date: Wed, 18 Jul 2018 08:41:58 -0600 From: Ian Lepore <ian@freebsd.org> To: Warner Losh <imp@bsdimp.com>, "Rodney W. Grimes" <freebsd-rwg@pdx.rh.cn85.dnsmgr.net> Cc: "freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org> Subject: Re: One last item: CNS1102 support removal Message-ID: <1531924918.26036.71.camel@freebsd.org> In-Reply-To: <CANCZdfoaTnwtXih9rQ3%2B=KZCWRh9ZL8D3=QeJz7MeQtXbgP9xw@mail.gmail.com> References: <CANCZdfqYRPKTRBjWLM5K=qd1OAMGqFiKeQDBcWgORA5kxh_uLQ@mail.gmail.com> <201807181416.w6IEGToZ007635@pdx.rh.CN85.dnsmgr.net> <CANCZdfoaTnwtXih9rQ3%2B=KZCWRh9ZL8D3=QeJz7MeQtXbgP9xw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1531924918.26036.71.camel>