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

On Wed, 15 Dec 2021 10:11:16 -0800
Gleb Smirnoff <glebius@freebsd.org> wrote:

> 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'm sure that if one looks deep enough, a lot of obsolete hardware
that we've removed are still produced by some industrial computer maker.
 And I don't think that this is a valid reason to keep everything that
is old.

> 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.

 No we don't, see :
https://cgit.freebsd.org/src/tree/sys/modules/Makefile#n772

> 2) Drivers don't contain native precompiled code. They contain
>    obfuscated code.

 Ok, I actually didn't looked, just noticed that they where listed
under MK_SOURCELESS_HOST.

> 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?

 They don't really create a burden.
 The reason that made me look at this is that I've noticed that my
FreeBSD-runtime package had this sconfig binary that I've never heard
of before. After digging I saw that it was for those old cards.
 I honestly don't care if we keep the drivers as of today we only
compile them for i386. I don't think that we should enable them for
amd64, we've lived ~20 years on amd64 without them, nobody complained
that they weren't present so clearly nobody cares about having them. We
shouldn't enable drivers on some arch just "because we can".
 With a46856c3f9ec in main right now I'm perfectly happy as I don't
have some useless tool, if it could stay that way that would be great.

 But it will be nice to have some kind of official statement on what
FreeBSD should deliver in term of drivers, I think we're way too
conservative on keeping old stuff that nobody uses just because "it
compiles".

 Cheers,

-- 
Emmanuel Vadot <manu@bidouilliste.com> <manu@freebsd.org>