On 30 August 2011 16:05, Manuel Bouyer <bou...@antioche.eu.org> wrote:

> On Tue, Aug 30, 2011 at 10:19:20AM -0400, Christos Zoulas wrote:
> > On Aug 30,  3:18pm, bou...@antioche.eu.org (Manuel Bouyer) wrote:
> > -- Subject: Re: netbsd32 emulation in driver open() or read()
> >
> > | > Yes, look at PK_32 in the process flags. If you are going to do this,
> please
> > | > look at what FreeBSD did with bpf_ts/bpf_xhdr and the time format
> changes
> > | > and do the same (provide timespec/bintime etc). This is how they
> handle
> > | > compatibility mode too.
> > |
> > | This is related to the BIOCSTSTAMP ioctl isn't it ? I can see how it's
> used
> > | in kernel but I couldn't find it in userland. So, to me it looks like
> > | the old bpf_hdr is used most of the time ...
> > | I'm not sure if it's worth implementing BIOCSTSTAMP (and we have to
> assure
> > | compat for bpf_hdr anyway)
> >
> > Might as well bite the bullet and do the whole thing because with 10Gb+
> > ethernet what we have now just does not cut it.
>
> This is not only the BIOCSTSTAMP that we need then, but also the zero-copy
> stuff, and probably more. And userland tools to use it (because AFAIK
> freebsd's tcpdump still uses the old bpf_hdr ...)
>
> That may be nice to have, but won't help with my problem which is
> getting a N32 mips binary to talk to a N64 kernel.
>

If the structure was versioned to have 64 bit fixed sized timestamps, then
the problem goes away for new code, though it does leave a COMPAT50 issue
for older code...

Reply via email to