was On Sat, Jan 11, 2020 at 12:32 AM Guy Harris <guy@xxxxxxxxxxxx> wrote:
>
> On Jan 10, 2020, at 1:19 PM, Arnd Bergmann <arnd@xxxxxxxx> wrote:
>
> > On Fri, Jan 10, 2020 at 10:05 PM Rich Felker <dalias@xxxxxxxx> wrote:
> >>
> >> On Fri, Jan 10, 2020 at 09:49:03PM +0100, Arnd Bergmann wrote:
> >>> musl is moving to a default of 64-bit time_t on all architectures,
> >>> glibc will follow later. This breaks reading timestamps through cmsg
> >>> data with the HCI_TIME_STAMP socket option.
> >>>
> >>> Change both copies of hcidump to work on all architectures. This also
> >>> fixes x32, which has never worked, and carefully avoids breaking sparc64,
> >>> which is another special case.
> >>
> >> Won't it be broken on rv32 though? Based on my (albeit perhaps
> >> incomplete) reading of the thread, I think use of HCI_TIME_STAMP
> >> should just be dropped entirely in favor of using SO_TIMESTAMPNS -- my
> >> understanding was that it works with bluetooth sockets too.
> >
> > All 32-bit architectures use old_timeval32 timestamps in the kernel
> > here, even rv32 and x32. As a rule, we keep the types bug-for-bug
> > compatible between architectures and fix them all at the same time.
> >
> > Changing hcidump to SO_TIMESTAMPNS would work as well, but
> > that is a much bigger change and I don't know how to test that.
>
> If so, maybe I'll just do that for libpcap. Libpcap *does* have an API to request
>capturing with nanoseconds in tv_usec (and I plan to give it pcapng-flavored APIs
> to deliver higher-resolution time stamps, as well as metadata such as "incoming"
> vs. "outgoing", as well).
Sounds good to me, just make sure that you no longer reference
HCI_TIME_STAMP and it should be fine with both old and new libc
versions.
SO_TIMESTAMPNS was first added to the kernel in linux-2.6.22, which
is probably older than anything you care about, but I'm not sure what you
need to do to use it on bluetooth. It appears to have first been added along
with the monitor channel support in linux-3.4.
On a semi-related note, I see that there is a y2038 compatibility in the
libpcap definition of struct pcap_timeval, which uses a *signed* tv_sec
field. I assume the sizes of the fields cannot be changed, but it would
be good to investigate if you can just make it unsigned instead, changing
the supported time range from 1902...2038 to 1970...2106.
It probably makes sense to do this together with supporting nanosecond
timestamps. You could also consider changing the format to use a
64-bit nanosecond value starting at either 1970 or 1902 to give an
even larger range.
Arnd
