From owner-svn-src-head@freebsd.org Thu Aug 4 18:08:34 2016 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C0C5EBAE07B; Thu, 4 Aug 2016 18:08:34 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 4F4EC1D26; Thu, 4 Aug 2016 18:08:34 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Subject: Re: svn commit: r303733 - head/contrib/libpcap To: Bruce Evans References: <201608032008.u73K8dWe047330@repo.freebsd.org> <20160804124849.Y1045@besplex.bde.org> Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org From: Jung-uk Kim Message-ID: <764bf543-5f62-cc7b-1242-8beccdaecd61@FreeBSD.org> Date: Thu, 4 Aug 2016 14:08:26 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <20160804124849.Y1045@besplex.bde.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="WPUmx6nhvLfEEqmwUK46eCPiTf309HanG" X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2016 18:08:34 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --WPUmx6nhvLfEEqmwUK46eCPiTf309HanG Content-Type: multipart/mixed; boundary="qvEMT4Wq9tpuf0VRcrUTeAlBtQ0IlA91m" From: Jung-uk Kim To: Bruce Evans Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Message-ID: <764bf543-5f62-cc7b-1242-8beccdaecd61@FreeBSD.org> Subject: Re: svn commit: r303733 - head/contrib/libpcap References: <201608032008.u73K8dWe047330@repo.freebsd.org> <20160804124849.Y1045@besplex.bde.org> In-Reply-To: <20160804124849.Y1045@besplex.bde.org> --qvEMT4Wq9tpuf0VRcrUTeAlBtQ0IlA91m Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 08/03/16 11:40 PM, Bruce Evans wrote: > On Wed, 3 Aug 2016, Jung-uk Kim wrote: >=20 >> Log: >> Support nanosecond time stamps for pcap_dispatch(3) and pcap_loop(3).= >> >> Modified: >> head/contrib/libpcap/pcap-bpf.c >> >> Modified: head/contrib/libpcap/pcap-bpf.c >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> >> --- head/contrib/libpcap/pcap-bpf.c Wed Aug 3 19:23:22 2016 =20 >> (r303732) >> +++ head/contrib/libpcap/pcap-bpf.c Wed Aug 3 20:08:39 2016 =20 >> (r303733) >> @@ -1008,7 +1028,25 @@ pcap_read_bpf(pcap_t *p, int cnt, pcap_h >> if (pb->filtering_in_kernel || >> bpf_filter(p->fcode.bf_insns, datap, bhp->bh_datalen, >> caplen)) { >> struct pcap_pkthdr pkthdr; >> +#ifdef BIOCSTSTAMP >> + struct bintime bt; >> + >> + bt.sec =3D bhp->bh_tstamp.bt_sec; >> + bt.frac =3D bhp->bh_tstamp.bt_frac; >=20 > The names are very confusing since bt_sec and bt_frac are only misnamed= as > sec and frac in struct bintime. bt_* means BPF timestamp, not bintime. >> + if (p->opt.tstamp_precision =3D=3D PCAP_TSTAMP_PRECISION_= NANO) { >> + struct timespec ts; >> + >> + bintime2timespec(&bt, &ts); >> + pkthdr.ts.tv_sec =3D ts.tv_sec; >> + pkthdr.ts.tv_usec =3D ts.tv_nsec; >=20 > And this abuses tv_usec to hold nanoseconds. libpcap decided to "abuse" it few years ago, not to break ABI/API. http://www.tcpdump.org/manpages/pcap-savefile.5.html > Old code is even more confusing, and at least partly wrong. >=20 > X contrib/libpcap/pcap-bpf.c: pkthdr.ts.tv_usec =3D > bhp->bh_tstamp.tv_usec/1000; >=20 > This is to convert for tv_usec actually being tv_nsec on AIX. If the a= bove > works with no conversion, then it might work for AIX too. Of course. However, we don't maintain AIX. ;-) > X sys/net/bpf.c: struct timeval32 bh_tstamp; /* time stamp */ >=20 > Banal comment. The complexities are from what sort of timestamp this i= s. > It is obviously a timestamp. >=20 > This bh_tstamp is in struct bpf_hdr32 for the !BURN_BRIDGES case. Ther= e > is also struct timeval bh_timestamp in struct bpf_hdr. This header is > bogusly marked Obsolete. It is superceded by struct bpf_xhdr although we kept it for backward compatibility. New applications should avoid it. > X sys/net/bpf.c: hdr32_old.bh_tstamp.tv_usec =3D ts.bt_f= rac; >=20 > This is in the !BURN_BRIDGES && COMPAT_FREEBSD32 case. Since struct > timeval32 > always has a 32-bit tv_usec, this assignment discards the most signific= ant > bits in bt_frac but keeps the noise. >=20 > X sys/net/bpf.c: hdr_old.bh_tstamp.tv_usec =3D ts.bt_frac; >=20 > This is in the !BURN_BRIDGES && !COMPAT_FREEBSD32 case. Since tv_sec i= n a > normal timetamp is bogusly long, this accidentally preserves all of the= > bits > in bt_frac on 64-bit arches. On 32-bit arches, it loses the signal as = for > the COMPAT_FREEBSD32 case. Note struct bpf_ts is not struct bintime. Jung-uk Kim --qvEMT4Wq9tpuf0VRcrUTeAlBtQ0IlA91m-- --WPUmx6nhvLfEEqmwUK46eCPiTf309HanG Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJXo4SiAAoJEHyflib82/FGX0YIAI/E9KvCRHzud6RN9lLkCVeV vPDUispwCy/6W7AndExODK759XP+L0PhB7KKovyXjs4FIcA/lRQ5ewDJJJFFbtR+ hnnXY4wQ/PXbJAE0LV8kdLTdNsab9VQ2YQQH09d2rLlE4ek4yCJymofv3WdN+pzV eXvAKMvSc02ryCEl1iGaBEIaAw9vRb2pozLewyGNv1S21fPUO+rJ5bP0qu6DngEH OvjV4+bPUdCdVcxg16x+EUuMSFTAxPLamOo3MbzrsSFXwOu6Q3CrySW+bnf4ZKyX Cw2dwBBqvsqgIOkucXoLMAUulzNtIjNRHUD8kIKm8Al9VTZZvhR4yJQTQf+mMBE= =obGg -----END PGP SIGNATURE----- --WPUmx6nhvLfEEqmwUK46eCPiTf309HanG--