Re: netbsd32 emulation in driver open() or read()
On 30 August 2011 16:05, Manuel Bouyer 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...
Re: netbsd32 emulation in driver open() or read()
On Tue, Aug 30, 2011 at 03:41:25PM +, Eduardo Horvath wrote: > On Tue, 30 Aug 2011, Manuel Bouyer wrote: > > > 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. > > Hm, MIPS. In this case you may need to check the struct emul to > differentiate o32 and n32. Or do they have the exact same structure > layouts? All the different MIPS ABIs make my head spin. It shouldn't make a difference for this. I just tested a o32 tcpdump binary and it works ... -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: netbsd32 emulation in driver open() or read()
On Tue, Aug 30, 2011 at 04:51:51PM +0100, David Brownlee wrote: > 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... For new code that uses bpf_xhdr. If you don't change userland code (including third-party code which uses libpcap), it will still use bpf_hdr even if recompiled. We get this via a read(2), this can't be versionned as easily as we do for ioctl or syscall structures ... -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: netbsd32 emulation in driver open() or read()
On Tue, 30 Aug 2011, Manuel Bouyer wrote: > 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. Hm, MIPS. In this case you may need to check the struct emul to differentiate o32 and n32. Or do they have the exact same structure layouts? All the different MIPS ABIs make my head spin. Eduardo
Re: netbsd32 emulation in driver open() or read()
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. -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: netbsd32 emulation in driver open() or read()
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. christos
Re: netbsd32 emulation in driver open() or read()
On Mon, Aug 29, 2011 at 04:28:00PM +, Christos Zoulas wrote:
> In article <20110829151339.ga24...@asim.lip6.fr>,
> Manuel Bouyer wrote:
> >Hello,
> >I'm working on getting bpf(4) in a 64bit kernel play with a 32bit userland.
> >I've translated the ioctls, but I'm now stuck with read().
> >read(2) on a bpf device returns wire packets (no problems with this)
> >with a bpf-specific header in front of each packet. This bpf header is:
> >struct bpf_hdr {
> >struct bpf_timeval bh_tstamp; /* time stamp */
> > uint32_tbh_caplen; /* length of captured portion */
> > uint32_tbh_datalen; /* original length of packet */
> > uint16_tbh_hdrlen; /* length of bpf header (this struct
> >plus alignment padding) */
> >};
> >with:
> >struct bpf_timeval {
> >long tv_sec;
> > long tv_usec;
> >};
> >
> >and this is the problem (sizeof(bpf_timeval) changes).
> >It doens't look easy to just move struct bpf_timeval to fixed-size types
> >(compat issues, I guess this would require a rename of open() or read()).
> >On the other hand, if bpf(4) did know if the program doing the
> >open() syscall is 32 or 64bits, it could appends the right header
> >(could also be done in read() but it's less easy: it would require
> >translating an existing buffer; while flagging it at open() time
> >allows to build the right buffer from start).
> >So: is there a way to know if the emulation used by a userland program
> >doing an open() is 32 or 64bit ?
>
> 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)
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
Re: netbsd32 emulation in driver open() or read()
In article <20110829151339.ga24...@asim.lip6.fr>,
Manuel Bouyer wrote:
>Hello,
>I'm working on getting bpf(4) in a 64bit kernel play with a 32bit userland.
>I've translated the ioctls, but I'm now stuck with read().
>read(2) on a bpf device returns wire packets (no problems with this)
>with a bpf-specific header in front of each packet. This bpf header is:
>struct bpf_hdr {
>struct bpf_timeval bh_tstamp; /* time stamp */
> uint32_tbh_caplen; /* length of captured portion */
> uint32_tbh_datalen; /* original length of packet */
> uint16_tbh_hdrlen; /* length of bpf header (this struct
> plus alignment padding) */
>};
>with:
>struct bpf_timeval {
>long tv_sec;
> long tv_usec;
>};
>
>and this is the problem (sizeof(bpf_timeval) changes).
>It doens't look easy to just move struct bpf_timeval to fixed-size types
>(compat issues, I guess this would require a rename of open() or read()).
>On the other hand, if bpf(4) did know if the program doing the
>open() syscall is 32 or 64bits, it could appends the right header
>(could also be done in read() but it's less easy: it would require
>translating an existing buffer; while flagging it at open() time
>allows to build the right buffer from start).
>So: is there a way to know if the emulation used by a userland program
>doing an open() is 32 or 64bit ?
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.
christos
Re: netbsd32 emulation in driver open() or read()
On Mon, 29 Aug 2011, Manuel Bouyer wrote: > So: is there a way to know if the emulation used by a userland program > doing an open() is 32 or 64bit ? sys/proc.h: 1.233 ad343: /* 1.273 ad344: * These flags are kept in p_flag and are protected by p_lock. Access from 1.233 ad345: * process context only. 346: */ ... 353: #definePK_32 0x0004 /* 32-bit process (used on 64-bit kernels) */ So you can check if that bit is set in the current proc's p_flag member. Eduardo
netbsd32 emulation in driver open() or read()
Hello,
I'm working on getting bpf(4) in a 64bit kernel play with a 32bit userland.
I've translated the ioctls, but I'm now stuck with read().
read(2) on a bpf device returns wire packets (no problems with this)
with a bpf-specific header in front of each packet. This bpf header is:
struct bpf_hdr {
struct bpf_timeval bh_tstamp; /* time stamp */
uint32_tbh_caplen; /* length of captured portion */
uint32_tbh_datalen; /* original length of packet */
uint16_tbh_hdrlen; /* length of bpf header (this struct
plus alignment padding) */
};
with:
struct bpf_timeval {
long tv_sec;
long tv_usec;
};
and this is the problem (sizeof(bpf_timeval) changes).
It doens't look easy to just move struct bpf_timeval to fixed-size types
(compat issues, I guess this would require a rename of open() or read()).
On the other hand, if bpf(4) did know if the program doing the
open() syscall is 32 or 64bits, it could appends the right header
(could also be done in read() but it's less easy: it would require
translating an existing buffer; while flagging it at open() time
allows to build the right buffer from start).
So: is there a way to know if the emulation used by a userland program
doing an open() is 32 or 64bit ?
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
