[Swan-dev] fyi, we've run out of impair+debug lset_t bits

[D. Hugh Redelmeier]

| From: Andrew Cagney <andrew.cagney at gmail.com>

| On Thu, 6 Sep 2018 at 11:53, Andrew Cagney <andrew.cagney at gmail.com> 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.