From owner-svn-src-all@freebsd.org Mon Aug 26 04:40:41 2019 Return-Path: Delivered-To: svn-src-all@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 6A999CEFD5 for ; Mon, 26 Aug 2019 04:40:41 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qt1-x842.google.com (mail-qt1-x842.google.com [IPv6:2607:f8b0:4864:20::842]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46GzpJ4wW2z3MxS for ; Mon, 26 Aug 2019 04:40:40 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qt1-x842.google.com with SMTP id y26so16763234qto.4 for ; Sun, 25 Aug 2019 21:40:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fB79W3XA56WQpyZIzrce2Y7iAmv9V6dJXuK7zltBSV8=; b=rT4v0ZswWrY6OZ94caBrN6/7BQEp57q6+1vymCzuflykMxK568Fi/vDsEF9XfaguBO vywPOcXI2KFtlIdKxGzs5SZzsUmgGNUeZVdeUgImpqVeWBqxUxm2Vr0DGkTL2rvh/JeU 6R+skQh4bKJUotR9geaji1bhJZEuHYjSj8/3jcUeZoGIP4fE+O68jXCB77RDO7dUot0z 1hsiIU/wEewQnz1MIjvvDVAbyH51apQiwZdxzhBxZSqz1cGXmSSHe9OaLSzvT7m/B8TR F/xocbmCEpkuXMLpcr5IgTe/ojXV8cKd3INi4aEFYqNAhIZxQD1Tj4ZmBLuspRDTq58O eGBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=fB79W3XA56WQpyZIzrce2Y7iAmv9V6dJXuK7zltBSV8=; b=YmCWhCgbnxEuM40+PduCDLm5Ha4UeIDu2gP3WszWC+/0Uk/dMZBwwcNrimS+PxY91N Z+Ac5WBtLbZ+ZcEoe/NCtUCVfLR8kkh6ewOA4cEHeO1zP9uk8N0QSX1KbD9E3pjiET45 Py06xHV5v76Wg/OdlLBc5WuoJtMFv7wa/KaGDigbQ2SvmILrJaGJPGkeoXa3y7YsS5t6 iffsqxax4hQV8kRcoGPgCvgni6fBeReYw+iD3LEeHvQNBpDTkyHE4mHy8G1EZ9L+W2a9 BIREr1i3mSV7usHMLTCOrHZe2yAGQGZ2xSJN41x8ikvZmcO0rGr+10WQxcVkpiarkukX IpEA== X-Gm-Message-State: APjAAAVtYPGaxeAJJpWFmdxFUCdyZecaSRfzIamDvkp/82SIonkXNy2E 5fJ1/VhG9FtGfUig4SpQR2TevJ2hNrjbyZqmnFydSQ== X-Google-Smtp-Source: APXvYqyacxT0XCsDJapjok8mNpQtJFtQMuYmj3JEZw01zs/Vm0sZDqiyxc/Hi94QqbKslLIFjOo1Cw+nzsrDRvXdMzA= X-Received: by 2002:ac8:4602:: with SMTP id p2mr15860269qtn.291.1566794439418; Sun, 25 Aug 2019 21:40:39 -0700 (PDT) MIME-Version: 1.0 References: <201908231522.x7NFMLuJ068037@repo.freebsd.org> <20190826.042056.1329861772202588895.hrs@allbsd.org> <20190826.050922.1810654532466043358.hrs@allbsd.org> <379c3378-f9dd-4d6b-35ca-fa1ac7e6386b@gmail.com> In-Reply-To: <379c3378-f9dd-4d6b-35ca-fa1ac7e6386b@gmail.com> From: Warner Losh Date: Sun, 25 Aug 2019 22:40:27 -0600 Message-ID: Subject: Re: svn commit: r351423 - in head: . sbin/ping6 sbin/ping6/tests To: Jan Sucan Cc: Alan Somers , "Conrad E. Meyer" , Hiroki Sato , src-committers , svn-src-all , svn-src-head X-Rspamd-Queue-Id: 46GzpJ4wW2z3MxS X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=rT4v0Zsw; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::842) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-3.59 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[svn-src-all@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; NEURAL_HAM_SHORT(-0.99)[-0.986,0]; RCVD_IN_DNSWL_NONE(0.00)[2.4.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; RCPT_COUNT_SEVEN(0.00)[7]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; FREEMAIL_TO(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; IP_SCORE(-0.61)[ip: (2.22), ipnet: 2607:f8b0::/32(-2.87), asn: 15169(-2.33), country: US(-0.05)]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2019 04:40:41 -0000 On Sun, Aug 25, 2019, 10:35 PM Jan Sucan wrote: > Hello, > > I can implement it. I suppose that ping6's manual page should be kept it > this case. > The differences are small enough you may be able to combine man pages. I was also thinking about printing a warning for each option renamed to > lead a willing user to use the new unified option set of ping. It could > be either only with -v, or by default and suppressed with -q. Or should > the option translation be completely transparent? > This I'm unsure about., so I'll leave it to others to opine. Warner -Jan > > On 26. 8. 2019 1:58, Alan Somers wrote: > > Jan (please keep him CCed on replies) has been musing about the same > > thing. That might satisfy everyone. Jan, would it be straightforward > > to implement? > > -Alan > > > > On Sun, Aug 25, 2019 at 5:51 PM Conrad Meyer wrote: > >> Hi Alan, Hiroki, > >> > >> It would be pretty easy to install a `ping6` link to the `ping(8)` > >> binary with different option parsing (conditional on argv[0]). That > >> removes most of the issues of code and space duplication, I think? > >> And the goal would be for the 'ping6' name to retain option > >> compatibility with historical ping6. > >> > >> It's not an uncommon pattern; for example, 'id', 'groups', and > >> 'whoami' are all a single binary with multiple linked names. Another > >> example is Clang, which provides 'cc', 'c++', 'clang', 'clang-cpp', > >> 'clang++' and 'cpp' links to the same inode =E2=80=94 and those have v= ery > >> different behavior depending on argv[0]. > >> > >> It's less work than forcing the ping6 compatibility crowd to create a > >> port and doesn't hurt ping(8) much, AFAICT. Is it an acceptable > >> middle ground? > >> > >> Best, > >> Conrad > >> > >> On Sun, Aug 25, 2019 at 1:26 PM alan somers wrote: > >>> On Sun, Aug 25, 2019, 2:11 PM Hiroki Sato wrote: > >>>> Alan Somers wrote > >>>> in SKvh1ZoiMAcagQJjPaRSvkML9J+BgpQsz5uNNbw@mail.gmail.com>: > >>>> > >>>> as> On Sun, Aug 25, 2019 at 1:22 PM Hiroki Sato > wrote: > >>>> as> > > >>>> as> > Hi, > >>>> as> > > >>>> as> > Alan Somers wrote > >>>> as> > in <201908231522.x7NFMLuJ068037@repo.freebsd.org>: > >>>> as> > > >>>> as> > as> Author: asomers > >>>> as> > as> Date: Fri Aug 23 15:22:20 2019 > >>>> as> > as> New Revision: 351423 > >>>> as> > as> URL: https://svnweb.freebsd.org/changeset/base/351423 > >>>> as> > as> > >>>> as> > as> Log: > >>>> as> > as> ping6: Rename options for better consistency with ping > >>>> as> > as> > >>>> as> > as> Now equivalent options have the same flags, and > nonequivalent options have > >>>> as> > as> different flags. This is a prelude to merging the two > commands. > >>>> as> > as> > >>>> as> > as> Submitted by: J=C3=A1n Su=C4=8Dan > >>>> as> > as> MFC: Never > >>>> as> > as> Sponsored by: Google LLC (Google Summer of Code 2019= ) > >>>> as> > as> Differential Revision: > https://reviews.freebsd.org/D21345 > >>>> as> > > >>>> as> > I have an objection on renaming the existing option flags in > ping6(8) > >>>> as> > for compatibility with ping(8). > >>>> as> > > >>>> as> > Is it sufficient to add INET6 support to ping(8) with > consistent > >>>> as> > flags and keep CLI of ping6(8) backward compatible? People > have used > >>>> as> > ping6(8) for >15 years, so it is too late to rename the > flags. I do > >>>> as> > not think the renaming is useful if "ping -6 localhost" or > "ping ::1" > >>>> as> > works. > >>>> as> > > >>>> as> > -- Hiroki > >>>> as> > >>>> as> If ping works with inet6, then why would we want to keep a > separate > >>>> as> tool around? If it's just for the sake of people who don't want > to or > >>>> as> can't update scripts, would a version in ports suffice? > >>>> > >>>> Because removing (or renaming) it causes a POLA violation. Do we > >>>> really have a strong, unavoidable reason to force people to rewrit= e > >>>> their script now? This is still a fairly essential and actively > used > >>>> tool, not like rcp or rlogin. Although deprecating ping6(8) and > >>>> removing it from the base system in the future release at some poi= nt > >>>> may work, changing the existing interface will simply confuse peop= le > >>>> who have used IPv6 for a long time. > >>>> > >>>> In my understanding, the purpose to integrate ping(8) and ping6(8) > >>>> into a single utility is to provide a consistent CLI and reduce > >>>> duplicate code, not to break compatibility. > >>>> > >>>> -- Hiroki > >>> > >>> Those goals are incompatible. We can't provide a consistent CLI > without breaking compatibility because ping and ping6 have conflicting > options. And we can't keep ping6 around while also removing duplicate co= de > because that would be, well, duplicate code. > >>> > >>> When would be a better time than a major version bump to make a chang= e > like this? > >>> > >>> The lack of a ping6 command in freebsd 13 should serve as a pretty > obvious reminder that scripts will need updating. I think that putting a > version of ping6 in ports should be a sufficient crutch for those who nee= d > it, don't you? > > >