On Wed, Aug 17, 2016 at 10:39:51AM +0100, Stuart Henderson wrote:
> On 2016/08/17 10:11, Peter Hessler wrote:
> > It sure would be nice if we could see the PID of the process that added
> > routes. Heck, route(8) even tries to print them already.
> >
> > Add the fields to the appropriate struct, and while here, document which
> > fields are in sync.
> >
> > (requested by krw@)
> >
> > OK?
> >
> >
> > Index: net/if.h
> > ===================================================================
> > RCS file: /cvs/openbsd/src/sys/net/if.h,v
> > retrieving revision 1.177
> > diff -u -p -u -p -r1.177 if.h
> > --- net/if.h 10 Jun 2016 20:33:29 -0000 1.177
> > +++ net/if.h 19 Jul 2016 13:41:53 -0000
> > @@ -267,6 +267,7 @@ struct if_msghdr {
> > int ifm_addrs; /* like rtm_addrs */
> > int ifm_flags; /* value of if_flags */
> > int ifm_xflags;
> > + pid_t ifam_pid; /* identify sender */
> > struct if_data ifm_data;/* statistics and other data about if */
> > };
>
> should this be ifm not ifam?
>
> it might be better after ifm_data (probably won't pack as well, but
> I think lower impact on software using if_msghdr).
>
No the goal is to keep the pid at the same offset of all routing messages
no matter what type. The drawback is that this is a ABI change and we need
to double check that it is possible to hump over this without breaking
network.
> >
> > @@ -286,6 +287,7 @@ struct ifa_msghdr {
> > int ifam_addrs; /* like rtm_addrs */
> > int ifam_flags; /* value of ifa_flags */
> > int ifam_metric; /* value of ifa_metric */
> > + pid_t ifam_pid; /* identify sender */
> > };
>
> I'll try to figure out ports impact of this, but it probably won't be today.
>
--
:wq Claudio
