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

  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?

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.

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.

-- 
Gleb Smirnoff