Re: route(8) and old messages

[christos%zoulas.com@localhost (Christos Zoulas)]

On Aug 16,  7:01pm, roy%marples.name@localhost (Roy Marples) wrote:
-- Subject: Re: route(8) and old messages

| On 16/08/2018 13:08, Christos Zoulas wrote:
| > I think that it is time to re-think how the routing socket works. Having
| > each program and the kernel deal with sending and receing all versions of
| > all messages is wasteful and painful to maintain. In the short term we
| > should fix things to use a message filter to indicate interest on the
| > message types they are interested, but the question is what to do in
| > the long term...
| 
| We already have a message filter.
| Here's the route(4) snippet:
| 
|       A process can specify which route message types it's interested in by
|       passing an array of route messsage types to the setsockopt(2) call 
| with
|       the RO_MSGFILTER option at the PF_ROUTE level.  For example, to 
| only get
|       specific messages:
| 
|             unsigned char rtfilter[] = { RTM_IFINFO, RTM_IFANNOUNCE };
| 
|             if (setsockopt(routefd, PF_ROUTE, RO_MSGFILTER,
|                 &rtfilter, (socklen_t)sizeof(rtfilter)) == -1)
|                     err(1, "setsockopt(RO_MSGFILTER)");
| 
| I think I've patched all the programs in base to use this already, 
| including src/external.
| So the only pain is really maintaining the backwards compatible stuff in 
| the kernel which we're kinda bound to do as part of NetBSD anyway.

Oh I did not know that we had patched every userland program to use the
filter. I was suggesting that we did that.

| The exception to this is route(8) as kre rightfully pointed out we need 
| to use it to verify the old messages are sent so filtering probably 
| doesn't apply. I'm thinking about adding support to route(8) to decode 
| the old messages as well, but not for SMALL binaries.

That would be helpful.

| If there is anything better we can do long term, I'm sure out of ideas 
| right now.

Looks like the way that we are evolving the routing socket API is very
expensive and error prone. If we designed the individual messages differently
(so that they could be extended at the end) perhaps it would be cheaper
to fix in the future.

Best,

christos