Import src/sys/sys/hash.h from OpenBSD/NetBSD

[Andre Oppermann]

Gleb Smirnoff wrote:
> 
> On Tue, Mar 14, 2006 at 01:42:54PM +0100, Andre Oppermann wrote:
> A> > On Fri, Mar 10, 2006 at 03:28:10PM +0000, Florent Thoumie wrote:
> A> > F> > > > FYI (if you're not reading -ports or -net), I just sent a prototype for
> A> > F> > > > the openospfd port.
> A> > F> > > Cool, thanks!  I'm happy if you maintain the port as I've never done a port
> A> > F> > > before.
> A> > F> >
> A> > F> > IMHO, Open{BGP,OSPF}D belong in src/contrib, not in ports/net.
> A> > F>
> A> > F> I'd be more than happy to see them in src/contrib.
> A> >
> A> > Me too.
> A> >
> A> > Question to Andre: what do we need to merge/add to our kernel to
> A> > run OpenBGPd+OpenOSPFd with all their features?
> A>
> A> Two more things I want to commit later today.  One is the addition of
> A> strtonum() to libc and the other is a small change to the routing socket to
> A> make it possible to change just the flags on a route instead of replacing
> A> the entire route.  That's it to get all standard functionality running.
> 
> Good!
> 
> A> Beyond that we have to fix our IPSEC API (I'm not sure whose fault it is,
> A> but Open- and FreeBSD are not fully compatible) and we have to finish the
> A> TCPMD5 support in the kernel.
> 
> Yes, I remember about TCP MD5.
> 
> What about choosing route using administrative distance of the protocol? Does
> this feature exist in Open(BSD+BGPdOSPFd)? Is it possible OSPF and BGP to
> inject same route into kernel, and kernel prefers the OSPF one until it
> is present, and then switches to BGP? This is what we have in zebra, where
> the zebra daemon performs this task - choosing between routes originated
> from different protocols. Since OpenBSD doesn't have this intermediate
> daemon, I guess they do the choosing process in kernel. Is this correct or
> I mistake?

They tag (PROTO[1|2]) their routes and OSPF may overwrite BGP routes. When
OSPF removes a route BGP will insert its own again.  Claudio and I want to
make this more formal and more in the way you describe it above.  That then
needs approriate kernel functionality.  We are currently debating the
semantics to find a good solution for both the routing daemon and kernel
hackers. ;)  We'll float a proposal in the near future.

-- 
Andre