Re: route(4): Adding ROUTE_MSGFILTER socket option

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

    Date:        Wed, 5 Apr 2017 11:00:35 +0100
    From:        Roy Marples <roy%marples.name@localhost>
    Message-ID:  <aafd749a-2883-6aef-568f-fc8b6db26e3b%marples.name@localhost>

  | Comments welcome!

Looks mostly good to me, with a caveat, and the same / a similar mechanism
would also be useful for the mobility socket (which is a clone of the
routing socket) if we ever add the Mobile IP code - and could probably be
used for generic raw sockets (aka ping and such) with a very similar
filter function.

The one issue I have is that ...

+	/* If the rtm type is filtered out, return a positive. */
+	if (!(rop->rocb_msgfilter & (1 << rtm->rtm_type)))
+		return EEXIST;

doesn't handle the full range of possible rtm_type values in any kind of
rational way, and if we define it like this now, there's no good way to
extend the API if rtm_type >= 32 ever gets defined (which as, if I count
properly, rtm_type's go up to 21 now, is not beyond belief).

I don't see a need to do a full select() type variable length bitmask, as
here the aim is to drop trash - if we don't guarantee in the API spec to
drop all junk (just to always deliver the requested packets - with perhaps
some more included just by "accident") then this could be ...

	if (!(rop->rocb_msgfilter & (1 << route_filter_mask[rtm->rtm_type])))
		return ...

where we have (a global, as it would be used by more than 1 func):

	static char /* or int */ route_filter_mask[256] = {
		0, 1, 2, 1, 3, 1, 2, 4, ... /* no values > 31 */
	};

with no API to set or query those values, so they can be changed at any
time (the initial settings would be 0,1,2,3,4,5,...,21,22,23,31,31,31,31,31...
so initially there would be a 1:1 mapping between filter bits and defined
rtm_type values, just as in the proposal, but no-one outside the kernel would
actually know that.)

When rtm_type values > 31 appear, then the values can be rearranged, possibly
with the types that apps tend to want together sharing a bit mask position,
and message types almost no-one wants retaining a unique bitmask value, and
if necessary allowing the rarer types (less frequently occurring) to all
share the same filter bit.   It would also allow (by internal kernel change
only, no user level visible 
change) the bit mask to be switched to 64 bits
if desired.

The method of setting filters would need to change, the app would need to pass
in a specific rtm_type value instead of a bitmask, and have that added to
the existing set - that op, and a "clear the filter" is all that should be
needed - a typical application is never likely to want to delete filters (no
longer receive some messages it earlier wanted) - if they do they can just
clear and start again (and the app can remember what types were previously
included) nor is there any real need query what is set (though that could
be included if needed - it would just return all the rtm_types that map into
a set filter bit -- even though that would allow apps to discover the approx
content (the equivalences anyway) of the route_filter_mask array if they
really wanted to.)

kre