svn commit: r351423 - in head: . sbin/ping6 sbin/ping6/tests
Conrad Meyer
cem at freebsd.org
Sun Aug 25 23:51:08 UTC 2019
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 — and those have very
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 <asomers at gmail.com> wrote:
>
> On Sun, Aug 25, 2019, 2:11 PM Hiroki Sato <hrs at allbsd.org> wrote:
>>
>> Alan Somers <asomers at freebsd.org> wrote
>> in <CAOtMX2hLxx=SKvh1ZoiMAcagQJjPaRSvkML9J+BgpQsz5uNNbw at mail.gmail.com>:
>>
>> as> On Sun, Aug 25, 2019 at 1:22 PM Hiroki Sato <hrs at allbsd.org> wrote:
>> as> >
>> as> > Hi,
>> as> >
>> as> > Alan Somers <asomers at FreeBSD.org> wrote
>> as> > in <201908231522.x7NFMLuJ068037 at 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án Sučan <sucanjan at gmail.com>
>> 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 rewrite
>> 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 point
>> may work, changing the existing interface will simply confuse people
>> 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 code because that would be, well, duplicate code.
>
> When would be a better time than a major version bump to make a change 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 need it, don't you?
More information about the svn-src-head
mailing list