svn commit: r312988 - in head/sys: compat/cloudabi compat/linux kern sys

[Edward Tomasz Napierala]

On 0201T1236, John Baldwin wrote:
> On Wednesday, February 01, 2017 10:23:37 AM Gleb Smirnoff wrote:
> > On Tue, Jan 31, 2017 at 02:13:36PM -0800, John Baldwin wrote:
> > J> On Monday, January 30, 2017 12:57:23 PM Edward Tomasz Napierala wrote:
> > J> > Author: trasz
> > J> > Date: Mon Jan 30 12:57:22 2017
> > J> > New Revision: 312988
> > J> > URL: https://svnweb.freebsd.org/changeset/base/312988
> > J> > 
> > J> > Log:
> > J> >   Add kern_listen(), kern_shutdown(), and kern_socket(), and use them
> > J> >   instead of their sys_*() counterparts in various compats. The svr4
> > J> >   is left untouched, because there's no point.
> > J> 
> > J> Note that you can compile test svr4 since it is still in the tree.
> > J> If we want to remove svr4, then we should remove it.  However, we
> > J> should maintain code that is in the tree if it is still there.
> > 
> > All we can do right now is maintain it as compilable. My example with
> > COMPAT_OLDSOCK shows that SVR4 simply doesn't work as kld, and nobody
> > complains.
> > 
> > Okay, what if I say on freebsd-arch/freebsd-current that I am going
> > to remove it and wait for any objections for a month, and then do it?
> 
> I would rather remove it than start skipping it in tree sweeps.  We should
> strive to maintain code that is in our tree.  If you can't get things tested,
> then we are better off removing the code instead of having it rot in the
> tree (cf the discussion on old ISA drivers).

On one hand you're right.  On the other - in this particular case including
svr4 (which I have no way of testing) in this sweep could break it, while
not touching it couldn't, as the old method continues to work.

Removing it is not a bad idea, though.  Gleb, would you?