Re: Any Cronyx Tau* (ce(4) or cp(4)) users ?

On Thu, 16 Dec 2021 07:01:30 -0800
Gleb Smirnoff <glebius@freebsd.org> 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 <manu@bidouilliste.com> <manu@FreeBSD.org>