Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 11 Feb 2017 12:55:48 +0000
From:      Edward Tomasz Napierala <trasz@freebsd.org>
To:        John Baldwin <jhb@freebsd.org>
Cc:        Gleb Smirnoff <glebius@freebsd.org>, svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org
Subject:   Re: svn commit: r312988 - in head/sys: compat/cloudabi compat/linux kern sys
Message-ID:  <20170211125548.GB3574@brick>
In-Reply-To: <148601396.h8ndg2hV6R@ralph.baldwin.cx>
References:  <201701301257.v0UCvNrK065993@repo.freebsd.org> <3349880.lYJPXOWCO7@ralph.baldwin.cx> <20170201182337.GG3334@FreeBSD.org> <148601396.h8ndg2hV6R@ralph.baldwin.cx>

next in thread | previous in thread | raw e-mail | index | archive | help
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?




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20170211125548.GB3574>