Another problem is bootstrapping address state that is to be maintained
by events received from PF_ROUTE. You must bootstrap using different
mechanism to that which will maintain the state:
Two obviousish problems:
a) not easy (near impossible?) to definitely correlate bootstrap state
to a point in the event-driven stream.
(ie you might miss stuff that happens that while you bootstrap)
b) the two mechanisms might not provide quite the same view of the
underlying state
(ie there might be quirks you have to adjust for)
Ideally, it'd be good if bootstrap and further events were delivered by
the kernel via the same band.
--paulj
On Tue, 9 Oct 2007, Darren Reed wrote:
> 1.
> The netinfo module provides a collection of net_* functions in
> the kernel, some of which provide indentical functionality to
> ioctls and while using said ioctls has not been possible from
> inside the kernel in the past, the kernel sockets project will
> change that.
>
> 2.
> When using ioctls for such things as gathering the address
> assigned to a network interface, it is necessary to use the
> lifreq structure. To the best of my knowledge, lifreq is an
> unstable interface, despite being documented in if(7p).
>
> 3.
> There is a need for the function calls *and* the data structures
> used here to be stable, so that there is no risk from a patch
> breaking them.
>
> 4.
> I'm not sure if someone who's using netinfo should also need
> to open a socket for the purpose of getting interface addresses,
> etc. It is tempting to add some sort of netinfo interface to the
> ioctl stuff that uses a kernel socket underneath but has a stable
> API up on top.
>
> Thoughts?
>
> Darren
>
> _______________________________________________
> networking-discuss mailing list
> [email protected]
>
--
Paul Jakma,
Solaris Networking Sun Microsystems, Scotland
http://opensolaris.org/os/project/quagga tel: EMEA x73150 / +44 15066 73150
_______________________________________________
networking-discuss mailing list
[email protected]
