| From: Andrew Cagney <[email protected]> | On Thu, 6 Sep 2018 at 11:53, Andrew Cagney <[email protected]> wrote:
Sorry for not replying sooner. | > Short term we can get some extra bits by splitting debug and impair so | > that they each have their own lset_t. That seems pretty clean and non-controversial. The original idea was that you could could have code selected by any of several debug options, with the test being a single making operation. Then when impairments were added, it seemed easy to graft them onto that mechanism. It had the right dataflow. I don't think that a test for any of several impairment settings is in our code. (Only a few places has more than one debug flag been tested. I think that we just haven't tuned our debugging code, but we should. Its a verbose mess.) | Turns out I need a lot more bits so ... Interesting. | > However, long term we'll need to come up with something different: | > expanding lset_t somehow, or even using a new structure. | | I grafted on a second mechanism that sends pluto a pair of integers | interpreted as WHAT:HOW (for instance, --impair ke-payload:omit) so | the lset_t limitation is removed. Old code can continue to use the | old flags. | | Andrew | | PS: I'm tempted to make the HOW a float so 'times' can also be sent | over, later ... PLEASE: NO TO FLOATS. They are the wrong abstraction. Time can be handled as scaled integers. _______________________________________________ Swan-dev mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan-dev
