From nobody Thu Dec 16 15:53:10 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 89E3B18DB961 for ; Thu, 16 Dec 2021 15:53:15 +0000 (UTC) (envelope-from glebius@freebsd.org) Received: from cell.glebi.us (glebi.us [162.251.186.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "cell.glebi.us", Issuer "cell.glebi.us" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JFGqH00PBz3P09; Thu, 16 Dec 2021 15:53:14 +0000 (UTC) (envelope-from glebius@freebsd.org) Received: from cell.glebi.us (localhost [127.0.0.1]) by cell.glebi.us (8.16.1/8.16.1) with ESMTPS id 1BGFrAuY009654 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 16 Dec 2021 07:53:10 -0800 (PST) (envelope-from glebius@freebsd.org) Received: (from glebius@localhost) by cell.glebi.us (8.16.1/8.16.1/Submit) id 1BGFrAAG009653; Thu, 16 Dec 2021 07:53:10 -0800 (PST) (envelope-from glebius@freebsd.org) X-Authentication-Warning: cell.glebi.us: glebius set sender to glebius@freebsd.org using -f Date: Thu, 16 Dec 2021 07:53:10 -0800 From: Gleb Smirnoff To: Emmanuel Vadot Cc: Ed Maste , FreeBSD Current Subject: Re: Any Cronyx Tau* (ce(4) or cp(4)) users ? Message-ID: References: <20211215162538.99d8d81650af56e2276f2f88@bidouilliste.com> <20211215175202.e1d101079a9c22c9094577f3@bidouilliste.com> <20211216101733.7b7bfa569aca496b22ef0324@bidouilliste.com> <20211216161337.1fa53758e61eaeb37b8b24d0@bidouilliste.com> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20211216161337.1fa53758e61eaeb37b8b24d0@bidouilliste.com> X-Rspamd-Queue-Id: 4JFGqH00PBz3P09 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-Spam: Yes X-ThisMailContainsUnwantedMimeParts: N Emmanuel, look at this communication: E> And we're doing that just because the drivers compiles ? G> We are doing that because the hardware is still produced ... E> ... a lot of obsolete hardware that we've removed are still produced ... G> I'd be interested to see at least one example ... E> This was an hypothetical situation. I don't know what to reply here. :( Now let's get constructive. E> > I'm not. Your position is simply: "the utility existence bugs me cause E> > it is useless for me", and "I don't care if it exist on i386, cause I E> > don't use i386". Kind of selfish position. E> E> What's selfish about removing some binary that 100% of our amd64 users E> never needed since the creation of FreeBSD/amd64 ? I agree that would be cool not to have stuff in the default install that is very unlikely to be used. On the other hand it would be cool that a device that is still in production doesn't require ancient FreeBSD to work. The latter requires to keep them in the build. The former requires not to have them installed. So what we need here is analog of LINT for the world build. A build that would cover all possible tools that aren't included into install. For example cxgbetool(8). Navdeep humbly put it in tools/tools initially. Later I asked him to move it to usr.sbin to make sure its build isn't broken. So it is installed, albeit 99% installations don't have Chelsio card. I think we can find more examples. So, proposed policy for such kind of devices is to have them in sys/conf/files and sys/conf/options and in LINT and do not have them in sys/modules/Makefile. Similarly for tools, to have them in the tree, enabled under 'lintworld' but not enabled under 'world'. Have WITH_SCONFIG and WITH_OTHERTOOL, but don't have it enabled by default. E> > I agree with that. We need such policy. It is being promised, and while E> > it is not there yet, there is this document: E> > E> > https://wiki.freebsd.org/DeprecationPlan E> > E> > As you see, a developer who wants to remove something needs to propose E> > that, communicate that and plan. And as you can see there, Cronyx devices E> > were proposed properly by Ed. The ISA ones were deleted quickly. For the E> > PCI ones I communicated Cronyx and checked their status. Later the E> > drivers were made as minimal as possible, removing sppp(4). This is a E> > proper process. Not do a drive by commit and refuse to revert it. E> E> Where did I refuse to revert ? May I ask you to revert it then, please? If you have time we can discuss and work on the above described policy of built but not included into default install devices/tools. P.S. If you really wish to deprecate something, I can suggest you to sacrifice sbni(4) :) -- Gleb Smirnoff