| From: Antony Antony <[email protected]> | To: D. Hugh Redelmeier <[email protected]> | Cc: Libreswan Development List <[email protected]> | Date: Fri, 23 Jan 2015 12:59:52 -0800 | Subject: Re: [Swan-dev] new delta time type | | The reason I didn't use timeval immediately in #libevent was due to lack | of arithmetic and configuration option parsing functions. Otherwise | timeval seems an obvious choice except when defining constants.
In the user-visible interface, everything up to now has been in seconds. The natural way to extend the interface is in terms of seconds with decimal fractions. I'm not saying that this should be the internal representation. I don't think that it is too hard to write our own code to do arithmetic on struct timeval given that we need to do so little arithmetic. If I tried, I might be surprised. The representation in libipsecconf should probably be a string, just to get around the floating point mess. Conversion from string to internal rep should appear one place for settings coming through whack and through conf file. In any case, I will argue elsewhere that these settings should be experimental at the moment, so a polished user interface may not be urgent. Alternative hack suggestion: time-valued parameters can have a suffix to specify the units. Maybe we need one (non-default) to specify milliseconds or microseconds (u?). That could stave off the requirement for decimal fractions (still the best way for humans, I think). Not perfect, just better than bare integers meaning different times in different contexts. | If we create a type it could be called delta_tv. I guess the | configuration parser should understand this and store the value in | delta_tv. arithmetic functions and parsing functions looks like a major | surgery:) I've done just enough with the config file parser that I think that it isn't too hard to hack. | If we use timeval, can we use something like | http://www.geonius.com/software/libgpl/tv_util.html ; If the license | compatible with libreswan? Looks plausible. But I don't think our own code would be very complex. | A consideration is mixing timeval with existing enum we have, such as | secs_per_day, secs_per_minute. I am not sure how to define constants for | struct timeval. If that also needs update it could quickly become a lot | of work. Float and int are most friendly to define constants. If we want to be fully general, I guess all times should be represented in wrapped struct timevals. I say "wrapped" because I want C to see them as separate types to protect us from mistakes. This is perhaps the best way to go. Since our old time types are wrapped already, this shouldn't be to hard. Of course this is overkill, but I'm not sure that the costs are significant. | One thought that is crossing my mind is why not use a float? We don't | want epoch, just delta timeval. So it could fit into float? Then | arithmetic and formatting become easier. Still there could be a need for | timeval to float and float to timeval conversion functions. Float has some appeal, for sure. But I hate floating point. It has a lot of non-intuitive failure modes. In the old days, I'd use the excuse that using any floating point adds overhead not worth paying. For example, the Linux kernel doesn't use floating point. But that argument is getting obsolete. | > microseconds. (Using "ms" in various names feels a little too specific.) | | How do you suggest we format the string? Until now it is only used in debug log Yeah. It's slightly tricky. I think that I fixed that formatting. With my fix, the problem is dealt with, but with a lot of trailing zero digits. Part of the problem is that I don't understand the use cases completely. For example, I don't think that we need to specify timeouts with microsecond precision so they don't need to be reported to that precision. I was suggesting struct timeval because we already need to use that representation. _______________________________________________ Swan-dev mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan-dev
