Re: [PATCH 1/6] rtnl: Track expiry times instead of lifetimes

Hi Andrew,

> So the lifetime stored in an l_rtnl_{route,address} without a
> reference time is useless once any time has passed from the lease
> receival or RA.  That's going to be the case for both l_netconfig
> internally and also the API user (caller of
> l_netconfig_get_addresses).

Right, but where does the caller get the reference time?  Calling l_time_now() 
possibly.  But lets say you got l_rtnl_route object by querying the kernel over 
rtnl.  The reference time is actually the timestamp of the rtnetlink message 
(which we probably should obtain as well).  So reference_time parameter use is 
just wrong in this context since the caller can't do the right thing.

I would remove this completely and either track the reference time internally in 
l_rtnl_{route|address}, or inside l_netconfig.

> 
> So internally I could wrap l_rtnl_{route,address} in a new private
> structre, but since it's also an issue for the public API I'd rather
> create new public classes, and they'd be very similar to
> l_rtnl_{route,address}.
> 

I'm not following? Why isn't validity time enough?

> New APIs outside of l_netconfig may end up having that problem too,
> the user can't tell if an addresses is still valid.
> 
> Remember we're basing l_netconfig on the idea that we don't set
> timeouts for addresses or routes.  Without timers I'll probably be
> purging expired addresses from the lists when
> l_netconfig_get_addresses() is called and at other entry points.

It isn't really a blanket ban on timers.  It is more to optimize the case of a 
repeated RAs being received and having to blast all the info into the kernel 
each time.  We can still set a timer for DHCP lease for example.  Also, we can 
hook into the main loop to be woken up every time an event fires and update 
whatever expiry times we have, and optionally take action if needed.

> 
> Note we already use l_rtnl_address in places where most of its
> contents are irrelevant.  I.e. we may only need 32 bits for each IPv4
> address (prefix length is common to the subnet) but we chose to use
> l_rtnl_address with the space overhead that it implies.  I thought the
> slight extra size of the timestamp shouldn't be an issue.

I'm mostly concerned about API use.  The 'reference' time is confusing to a pure 
rtnetlink user.

Regards,
-Denis