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

On Wed, Dec 15, 2021 at 05:52:02PM +0100, Emmanuel Vadot wrote:
E> > >  I've noticed this /sbin/sconfig binary and after looking it's for
E> > > configuring Cronyx E1 PCI (PCI as in PCI, not PCIe).
E> > >  The products pages ([1], [2]) seems to say that FreeBSD >=7 isn't
E> > > supported.
E> > >  We currently only build the drivers for i386 (and they contain native
E> > > compiled code).
E> > >
E> > >  Anyway, I'd like to remove this from the tree, I really doubt that
E> > > anyone uses this cards nowadays (or even E1) but just in case I send
E> > > this mail.
E> > 
E> > I posted a similar query to -stable in 2020, at
E> > https://lists.freebsd.org/pipermail/freebsd-stable/2020-February/092037.html
E> > and did not get any response.
E> > 
E> > I have D23928 for a deprecation notice for ce and cp. Gleb commented
E> > there that he'd offer to maintain them (and as part of that, removed
E> > sppp in 6aae3517ed25).
E> > 
E> 
E>  I'm not sure I understand the logic here.
E>  We're keeping drivers for museum grade hardware that no developer have
E> access to and likely no one uses nowadays just for an hypothetical
E> situation where someone will try to use those cards on FreeBSD 14 i386
E> in 2021 ?
E>  And we're doing that just because the drivers compiles ?

We are doing that because the hardware is still produced and can be
purchased at http://cronyx.ru/price/#taupci And this is not a dead
website, I gave a call to tech support last year. Who uses it? No
idea. For some obscure reason they are still produced along with
conventional PCI industrial mainboards (you can google that).

I agree that actual intersection of FreeBSD users and Cronyx
users could be zero today. But potentially it can be non-zero.
I would appreciate if somebody chooses FreeBSD for their very
strange industrial communications equipment.

Some corrections on above statements.

1) We build cp(4) on amd64. We don't build ce(4) on amd64 for a
   reason that some functions are marked with __attribute__ fastcall.
   I'm 99% sure that attribute can be removed and ce(4) will build
   on amd64. sconfig(8) is build on amd64.
2) Drivers don't contain native precompiled code. They contain
   obfuscated code.

Does sconfig create any problems for you? I'm fine with removing
the drivers and the tool if they do really create a burden for us.
That was case with their sppp(4) half, and I removed it in 6aae3517ed25.
If there is no maintainance burden, why remove them? Just to save
disk space?

-- 
Gleb Smirnoff