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

D. Hugh Redelmeier hugh at mimosa.com
Thu Sep 20 04:54:03 UTC 2018

| 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

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 ...


| > 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.

More information about the Swan-dev mailing list