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

  Emmanuel,

look at this communication:

E> And we're doing that just because the drivers compiles ?
G> We are doing that because the hardware is still produced ...
E> ... a lot of obsolete hardware that we've removed are still produced ...
G> I'd be interested to see at least one example ...
E> This was an hypothetical situation.

I don't know what to reply here. :(

Now let's get constructive.

E> > I'm not. Your position is simply: "the utility existence bugs me cause
E> > it is useless for me", and "I don't care if it exist on i386, cause I
E> > don't use i386". Kind of selfish position.
E> 
E>  What's selfish about removing some binary that 100% of our amd64 users
E> never needed since the creation of FreeBSD/amd64 ?

I agree that would be cool not to have stuff in the default install that
is very unlikely to be used. On the other hand it would be cool that a
device that is still in production doesn't require ancient FreeBSD to
work. The latter requires to keep them in the build. The former requires
not to have them installed. So what we need here is analog of LINT for
the world build. A build that would cover all possible tools that aren't
included into install. For example cxgbetool(8). Navdeep humbly put it
in tools/tools initially. Later I asked him to move it to usr.sbin to
make sure its build isn't broken. So it is installed, albeit 99% installations
don't have Chelsio card. I think we can find more examples.

So, proposed policy for such kind of devices is to have them in sys/conf/files
and sys/conf/options and in LINT and do not have them in sys/modules/Makefile.
Similarly for tools, to have them in the tree, enabled under 'lintworld' but
not enabled under 'world'. Have WITH_SCONFIG and WITH_OTHERTOOL, but don't
have it enabled by default.

E> > I agree with that. We need such policy. It is being promised, and while
E> > it is not there yet, there is this document:
E> > 
E> > https://wiki.freebsd.org/DeprecationPlan
E> > 
E> > As you see, a developer who wants to remove something needs to propose
E> > that, communicate that and plan. And as you can see there, Cronyx devices
E> > were proposed properly by Ed. The ISA ones were deleted quickly. For the
E> > PCI ones I communicated Cronyx and checked their status. Later the
E> > drivers were made as minimal as possible, removing sppp(4). This is a
E> > proper process.  Not do a drive by commit and refuse to revert it.
E> 
E>  Where did I refuse to revert ?

May I ask you to revert it then, please? If you have time we can discuss
and work on the above described policy of built but not included into
default install devices/tools.

P.S. If you really wish to deprecate something, I can suggest you to
sacrifice sbni(4) :)

-- 
Gleb Smirnoff