From nobody Thu Dec 16 15:13:37 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 E390418C24CE for ; Thu, 16 Dec 2021 15:13:39 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mx.blih.net (mail.blih.net [212.83.155.74]) (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 "mx.blih.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JFFxb3STwz3GWG; Thu, 16 Dec 2021 15:13:39 +0000 (UTC) (envelope-from manu@bidouilliste.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bidouilliste.com; s=mx; t=1639667617; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=e0DiTY/7ZCVwgCSl3cgPvJsYls5GeHala+Wm54eblHY=; b=Zm8mMUSKgn3LtfEp0yyk7mQ1j81D9i6+QCh2rcEYTlr3A7tfkJIs+52cEXUFROXSU6aeRL aSQ+2OMnnj3+41KBkSZVQk7qb6GcxwoX+PSD/6OLCMTBIG8HfI35mtmLZvUHwKiCNNNDdR 1xldiHVh5RPeMl5M7BLReMV5NHi2y+w= Received: from amy (lfbn-idf2-1-1163-183.w90-92.abo.wanadoo.fr [90.92.222.183]) by mx.blih.net (OpenSMTPD) with ESMTPSA id cb71995a (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Thu, 16 Dec 2021 15:13:37 +0000 (UTC) Date: Thu, 16 Dec 2021 16:13:37 +0100 From: Emmanuel Vadot To: Gleb Smirnoff Cc: Ed Maste , FreeBSD Current Subject: Re: Any Cronyx Tau* (ce(4) or cp(4)) users ? Message-Id: <20211216161337.1fa53758e61eaeb37b8b24d0@bidouilliste.com> In-Reply-To: References: <20211215162538.99d8d81650af56e2276f2f88@bidouilliste.com> <20211215175202.e1d101079a9c22c9094577f3@bidouilliste.com> <20211216101733.7b7bfa569aca496b22ef0324@bidouilliste.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.0) 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-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4JFFxb3STwz3GWG X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Thu, 16 Dec 2021 07:01:30 -0800 Gleb Smirnoff wrote: > Emmanuel, > > On Thu, Dec 16, 2021 at 10:17:33AM +0100, Emmanuel Vadot wrote: > E> > E> I'm not sure I understand the logic here. > E> > E> We're keeping drivers for museum grade hardware that no developer have > E> > E> access to and likely no one uses nowadays just for an hypothetical > E> > E> situation where someone will try to use those cards on FreeBSD 14 i386 > E> > E> in 2021 ? > E> > E> And we're doing that just because the drivers compiles ? > E> > > E> > We are doing that because the hardware is still produced and can be > E> > purchased at http://cronyx.ru/price/#taupci And this is not a dead > E> > website, I gave a call to tech support last year. Who uses it? No > E> > idea. For some obscure reason they are still produced along with > E> > conventional PCI industrial mainboards (you can google that). > E> > E> I'm sure that if one looks deep enough, a lot of obsolete hardware > E> that we've removed are still produced by some industrial computer maker. > E> And I don't think that this is a valid reason to keep everything that > E> is old. > > I'd be interested to see at least one example of removed driver for > a hardware that is still produced. Can you demonstrate one please? This was an hypothetical situation. > E> > I agree that actual intersection of FreeBSD users and Cronyx > E> > users could be zero today. But potentially it can be non-zero. > E> > I would appreciate if somebody chooses FreeBSD for their very > E> > strange industrial communications equipment. > E> > > E> > Some corrections on above statements. > E> > > E> > 1) We build cp(4) on amd64. We don't build ce(4) on amd64 for a > E> > reason that some functions are marked with __attribute__ fastcall. > E> > I'm 99% sure that attribute can be removed and ce(4) will build > E> > on amd64. sconfig(8) is build on amd64. > E> > E> No we don't, see : > E> https://cgit.freebsd.org/src/tree/sys/modules/Makefile#n772 > > Well, that was my miss, when I moved it from options.i386 to options.x86. > Forgot about modules. The Makefile also has a comment at line 764. > > With "we build" I meant that we can add it to kernel config and build. > > E> > Does sconfig create any problems for you? I'm fine with removing > E> > the drivers and the tool if they do really create a burden for us. > E> > That was case with their sppp(4) half, and I removed it in 6aae3517ed25. > E> > If there is no maintainance burden, why remove them? Just to save > E> > disk space? > E> > E> They don't really create a burden. > E> The reason that made me look at this is that I've noticed that my > E> FreeBSD-runtime package had this sconfig binary that I've never heard > E> of before. After digging I saw that it was for those old cards. > E> I honestly don't care if we keep the drivers as of today we only > E> compile them for i386. I don't think that we should enable them for > E> amd64, we've lived ~20 years on amd64 without them, nobody complained > E> that they weren't present so clearly nobody cares about having them. We > E> shouldn't enable drivers on some arch just "because we can". > E> With a46856c3f9ec in main right now I'm perfectly happy as I don't > E> have some useless tool, if it could stay that way that would be great. > > I'm not. Your position is simply: "the utility existence bugs me cause > it is useless for me", and "I don't care if it exist on i386, cause I > don't use i386". Kind of selfish position. What's selfish about removing some binary that 100% of our amd64 users never needed since the creation of FreeBSD/amd64 ? > For myself FreeBSD also contains quite a lot of tools I never use and > probably never would. > > E> But it will be nice to have some kind of official statement on what > E> FreeBSD should deliver in term of drivers, I think we're way too > E> conservative on keeping old stuff that nobody uses just because "it > E> compiles". > > I agree with that. We need such policy. It is being promised, and while > it is not there yet, there is this document: > > https://wiki.freebsd.org/DeprecationPlan > > As you see, a developer who wants to remove something needs to propose > that, communicate that and plan. And as you can see there, Cronyx devices > were proposed properly by Ed. The ISA ones were deleted quickly. For the > PCI ones I communicated Cronyx and checked their status. Later the > drivers were made as minimal as possible, removing sppp(4). This is a > proper process. Not do a drive by commit and refuse to revert it. Where did I refuse to revert ? -- Emmanuel Vadot