Re: route(4): Adding ROUTE_MSGFILTER socket option

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Wed, 5 Apr 2017 13:25:44 +0100
    From:        Roy Marples <roy%marples.name@localhost>
    Message-ID:  <7b696d45-0fee-7b0a-ce73-e8daf3120097%marples.name@localhost>


  | Right now I chose the same API, just so I can test and validate it works
  | the same on both OS's.

That's reaosnable for testing, but preferably not for comitting.

  | Also, when NetBSD started it has 11 types. Now it has 21, so that's an
  | extra 10 in 22 years, so at a rate of 1 every 2 years.

Most likely they come in bursts.

  | Strictly speaking, the types are beholden to the version so we could
  | just bump the version and remove the O (ie old) compat vars and bury
  | them to keep inside 32-bits. Thus would mean re-working how we handle
  | compat in rtsock though.

We could, but let's not - it is a 256 value field (or 255 since 0 appears
to not be used) and we should be able to cope with all values, and without
needing hackery any time in the future.

  | Well yes, but the point of the API is that we don't want them by
  | accident,

The scheme I proposed was intended to allow the kernel coder (when/if
it is required) to arrange to map the message types so that accidents
would be rare (that is combining in the bitmask values that tend to
be enabled together, and excluding the types that are not.)

But...

  | If avoiding a variable length bitmask is needed then we just need
  | something similar to poll

Yes, that's another option - anything to avoid 1 << 80 and similar...

The mapping scheme (I suggested) is likely cheaper in the kernel (just
one extra mem reference compared to your/OpenBSD's original during
packet processing) but a poll style interface is cleaner, and could
avoid all unwanted packets being delivered.

With the API you proposed in this message, either internel implementation
could be used, which is good - what matters most is that the application
sends the actual rtm_type values to the kernel, rather than calculating a
bitmask and sending that (as unless we do a select type interface, that
bitmask is of fixed length, and I don't think we want to make it a 32 byte
array to fit all possible bits in).

For now the kernel (packet processing) code could be just as you showed it
initially (just a 32 bit mask operation) just as long as the API does not
expose that.

  | as it's more efficient than select.

That depends upon usage, it is more effecient when only a few fd are
of interest, less when the app has hundreds (or more) and wants to know
about (almost) all of them ... but select vs poll isn't relevant here.

kre