Re: OR_AND semantics (was: GNU property saga)

[Michael Matz <matz@suse.de>]

Hello,

On Mon, 4 Mar 2019, Cary Coutant wrote:

> I'm guessing that HJ is operating under the premise that if the older 
> producer B was unaware of bit 5 of FEATURE_X, then the object must not, 
> in fact, use that feature. His design is all-or-nothing: If the 
> FEATURE_X property is there, then we have accurate yes/no information 
> for each feature described by that property. That would work if he's 
> careful to move a new feature to a completely new FEATURE_Y property 
> whenever it's possible that an older consumer might have used that 
> feature before the means of recording it was defined.

Yes, that's the implicit assumption theory I had.

> Jim and I each suggested an improvement where each feature is described 
> by two bits: one bit from FEATURE_X_KNOWN and a corresponding bit from 
> FEATURE_X_USED*. The bits in FEATURE_X_KNOWN would be ANDed, while the 
> bits in FEATURE_X_USED would be ORed. This would give us the following 
> four cases:

And yes, that would be my cut at designing such property feature as well.  
One set of bits that spells out what can be relied upon, and another set 
of bits that contains the actual used/unused state.  Nice, easy, obvious.

> I was trying to understand why HJ didn't care about case (b) -- if a
> feature is used by at least one object, what difference does it make
> whether we have some objects that didn't say whether they used the
> feature? I believe his answer is that the use case for these
> properties is to allow the OS to decide whether it can allocate a
> program to a downgraded processor, based on whether we know for sure
> that the program does *not* use a particular feature. Thus, case (c)
> is the important one where the downgrade is feasible, and all other
> cases mean that it is not (either because we know the feature is used,
> or because we do not know it's not used).

That might be, but truth be told, I'm more comfortable with an orthogonal 
design that can express more than we need right now, than with a design 
where two concepts (known and used) are merged in a non-natural way.

HJ: what's your issue with the KNOWN+USED approach?  I would envision an 
encoding where e.g. even IDs encode the 32 KNOWN bits, and odd IDs encode 
the 32 USED bits.  Optionally we could retain the differentiation between 
OR vs. AND for the logical combination of the USED bits (where the KNOWN 
bits are always ANDed), though I'm not sure I would see the point for 
this.

I really have stomach aches with the current design of the properties.


Ciao,
Michael.