Sebastien Marie <[email protected]> wrote: > I just wonder about the system behaviour after building a new kernel > and rebooting to build userland: RTP_PROPOSAL_SOLICIT is changed and > kernel/userland will mismatch. > > But UMB proposal was done this way too (moving RTP_PROPOSAL_SOLICIT to > next id). So disturb shouldn't be big.
This is a messy part of the route proposal mechanism. The messaging is a bit weird. We discussed eventually fixing, but never got around to it. The route priority code rt_priority is abused to signal the DNS resolver choice priority. resolvd sees proposals in the range RTP_PROPOSAL_STATIC to RTP_PROPOSAL_UMB (57 to 60), and uses this to sort output in the resolv.conf file. RTP_PROPOSAL_SOLICIT is a totally different kind of message in the opposite direction. Something bad might happens if a new prio code is placed on the other side of RTP_PROPOSAL_SOLICIT, so would not encourage that. rtm_type indicates RTM_PROPOSAL for all DNS resolver messages, so the priority code can be totally unique. Maybe we should move RTP_PROPOSAL_SOLICIT out of the sorted range. like make it 1?. The only goal being to make the range-to-be-sorted not contain it, even as we expand the priorities in the future... This would break compatibility only one more time.
