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? _______________________________________________ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
