Christos Zoulas <christos@zoulas.com> wrote:

> That is a cute idea. Do we really need the backwards compatibility though,
> at the expense of making the file a lot larger? 

The xheader could look like this: 

struct ktr_xheader {
        char    xh_version;             /* Extended header version */
        char    xh_comm[MAXCOMLEN+1];   /* command name */
        lwpid_t xh_lwpid;               /* lwpid */     
};

A lot of ktr_header can share the same ktr_xheader: while you trace the
same lwp, you point to the same ktr_xheader. That way it won't be that
big. Except of course if you have hundreds lwps, but if you do that I
assume you prepared a rather big machine :o)

> There is of course the
> following hack that gives backwards compatibility and lwpid if < 64K:
> 
> 
> struct ktr_header {
>       int     ktr_len;                /* length of buf */
> #if _BYTE_ORDER == _LITTLE_ENDIAN
>       u_short ktr_lwpid;              /* lwp id */
> #endif
>       u_short ktr_type;               /* trace record type */
> #if _BYTE_ORDER == _BIG_ENDIAN
>       u_short ktr_lwpid;              /* lwp id */
> #endif
>       pid_t   ktr_pid;                /* process id */
>       char    ktr_comm[MAXCOMLEN+1];  /* command name */
>       struct  timeval ktr_time;       /* timestamp */
>       void   *ktr_buf;
> };
> 
> Which is not that ugly, retains backwards compatibility and works unless
> you have more than 64K of lwps.

The xheader causes annoyance for older programs (the displayed name will
loose 4 chars, 8 chars on 64 bit machines), but don't you think
limitting lwpid to 64k could cause annoyance to future programs?

-- 
Emmanuel Dreyfus
Il y a 10 sortes de personnes dans le monde: ceux qui comprennent 
le binaire et ceux qui ne le comprennent pas.
manu@netbsd.org