Reading a book on Yocto. Got to the following page, which says:
BitBake provides a very easy-to-use way to write conditional metadata.
It is done by a mechanism called overrides.
The OVERRIDES variable contains values separated by colons (:), and
each value is an item we want to satisfy conditions. So, if we have a
variable that is conditional on arm, and arm is in OVERRIDES, then the
version of the variable that is specific to arm is used rather than
the non-conditional version, as shown:
OVERRIDES = "architecture:os:machine"
TEST = "defaultvalue"
TEST_os = "osspecificvalue"
TEST_other = "othercondvalue"
In this example, TEST will be osspecificvalue due to the condition
of os being in OVERRIDES.
I'm unclear from this explanation how did TEST become equal to osspecificvalue. Would someone be able to explain it?
Bitbake implements it's own dictionary data structure based on Python's MutableMapping in lib/bb/data_smart.py. The goal is to create a dictionary with more flexibility in that each value in the "key,value" pair can be overridden based on specific identifiers.
If you look at how the variables in this dictionary are set, you will see that the datastore allows "overrides" of variables based on a list of override identifiers. These identifiers are expected to be appended with an underscore, like in your example of "TEST_os".
In the case you are referencing, "other" identifier is not in the list of OVERRIDES, so this "smart dictionary" does not override the value of TEST with "othercondvalue". However, because the "os" identifier is in the list of OVERRIDES, the value of TEST is indeed overridden with the value "osspecificvalue".
I would highly recommend reading through the DataSmart class as this is a very simplified explanation, but hopefully it helps.
Also, see the BitBake manual entry for OVERRIDES for more information.
Related
I have a list of objects that need to be loaded into my app. But the load order matters. I’ve created a var which is a part of each object that indicates the load order where the lowest number gets loaded in first. Then I’ve set the default to be 9999. I can manually set this value on each object and override the default. Currently this is where I’m at.
Should I add more objects which need to be loaded in a specific order in the future, I want to make sure there are no conflicts. It seems to me like I could do that by making each load order number on the objects unique, (i.e. no duplicate numbers in all the load order variables).
Is there a way I can make Xcode throw an error or warning if it detects that anything conforming to a protocol has the same value on a variable from that protocol as any of the other conforming objects?
Well, you could list all the objects in an array literal in the order you want them loaded, and forgo the load order property entirely:
let objectsToLoad = [
ObjectDescriptor("hello"),
ObjectDescriptor("world"),
]
But if you have objects defined in disparate places and don't want a single unified array literal that lists them all, then I don't think you can get help from the compiler (or the linker).
In a few months, when Swift will have macros, you'll probably be able to get help from the compiler or the linker. The strategy is to use a macro to wrap each load-order constant in a macro that also generates some type definition whose name includes the constant, e.g. enum _LoadOrder_1 {}, enum _LoadOrder_357 {}, etc. Then, if you have a duplicate, either the compiler or the linker will fail due to the multiple definitions for a single identifier.
I found this code in arena.dart in the ffi examples of flutter:
/// The last [Arena] in the zone.
factory Arena.current() {
return Zone.current[#_currentArena];
}
I am puzzled and could not find anything about the #_currentArena thing. What type of language construct is that, and how does it work? Trying to name anything (else) starting with # gives immediate errors; auto completion doesn't find it, and trying to go to its definition doesn't work either.
So this seems to be something extremely special, and extremely undocumented... leaving me extremely curious!
Link to source file in Flutter SDK Sqlite Example
As #pskink pointed out in his comment, this is part of the symbols.
A Symbol object represents an operator or identifier declared in a
Dart program. You might never need to use symbols, but they’re
invaluable for APIs that refer to identifiers by name, because
minification changes identifier names but not identifier symbols.
To get the symbol for an identifier, use a symbol literal, which is
just # followed by the identifier:
#radix
#bar
Symbol literals are compile-time constants.
I am developer of the PKCS#11 library. I think that the function C_DeriveKey should fail with the error code
CKR_KEY_FUNCTION_NOT_PERMITTED
if the key has CKA_DERIVE=0.But this error code is not listed as a possible return value for C_DeriveKey in the specification document . What is the right error code to be returned by C_DeriveKey in this case?
I agree that the specification is not very clear on this case. There is a newer version of the specification available (v3.0 from March 2020, link), but it does not bring more clarity on this. I would make the following considerations:
General note on return values
The introduction on return values in section 5.1 gives the following disclaimer (link):
Because of the complexity of the Cryptoki specification, it is recommended that Cryptoki applications attempt to give some leeway when interpreting Cryptoki functions’ return values. We have attempted to specify the behavior of Cryptoki functions as completely as was feasible; nevertheless, there are presumably some gaps. For example, it is possible that a particular error code which might apply to a particular Cryptoki function is unfortunately not actually listed in the description of that function as a possible error code.
The last part directly acknowledges that the list of possible return values for each function may be incomplete. For that reason, C_DeriveKey not listing CKR_KEY_FUNCTION_NOT_PERMITTED as a possible return code may not be authoritative, if there are other reasons for why the function should return this value.
Definition of the return codes
Section 5.1.6 gives the following definitions (link):
CKR_KEY_FUNCTION_NOT_PERMITTED: An attempt has been made to use a key for a cryptographic purpose that the key’s attributes are not set to allow it to do. For example, to use a key for performing encryption, that key MUST have its CKA_ENCRYPT attribute set to CK_TRUE (the fact that the key MUST have a CKA_ENCRYPT attribute implies that the key cannot be a private key). This return value has lower priority than CKR_KEY_TYPE_INCONSISTENT.
CKR_KEY_TYPE_INCONSISTENT: The specified key is not the correct type of key to use with the specified mechanism. This return value has a higher priority than CKR_KEY_FUNCTION_NOT_PERMITTED.
From this definition I would conclude that CKR_KEY_TYPE_INCONSISTENT is not the right return code for the scenario we are discussing, because it relates the mechanism to the "type" of the key. If we understand "type" in the sense of CKA_KEY_TYPE, it is completely unrelated to the attribute CKA_DERIVE.
Moreover, the attribute CKA_ENCRYPT is given as an example in the definition of CKR_KEY_FUNCTION_NOT_PERMITTED. This attribute is very similar to CKA_DERIVE, i.e. CKA_ENCRYPT controlling whether the key can be used for encryption and CKA_DERIVE controlling whether the key can be used for deriving. Thus, if CKR_KEY_FUNCTION_NOT_PERMITTED is the right return code for the case when CKA_ENCRYPT is not set, it seems reasonable that it would also be the right return code for the case when CKA_DERIVE is not set.
Reference implementations
I looked at some PKCS#11 libraries to check how they handle the case that C_DeriveKey is called on a key with CKA_DERIVE set to CK_FALSE. Most of the implementations I found do not implement the C_DeriveKey function at all (i.e. they always return CKR_FUNCTION_NOT_SUPPORTED). For the libraries that do implement this function, I observed the following behaviors:
OpenSC returns CKR_KEY_TYPE_INCONSISTENT (reference):
CK_ATTRIBUTE derive_attribute = { CKA_DERIVE, &can_derive, sizeof(can_derive) };
...
rv = object->ops->get_attribute(session, object, &derive_attribute);
if (rv != CKR_OK || !can_derive) {
rv = CKR_KEY_TYPE_INCONSISTENT;
goto out;
}
I also checked how OpenSC handles the other attributes that are similar to CKA_DERIVE. It seems the C_EncryptInit function is not implemented in OpenSC (presumably because this is a public key operation?), but C_DecryptInit is. This function implements a check for CKA_DECRYPT (reference), but returns CKR_KEY_TYPE_INCONSISTENT, which goes against the example that was given in the specification of CKR_KEY_FUNCTION_NOT_PERMITTED.
SoftHSMv2 returns CKR_KEY_FUNCTION_NOT_PERMITTED (reference):
// Check if key can be used for derive
if (!key->getBooleanValue(CKA_DERIVE, false))
return CKR_KEY_FUNCTION_NOT_PERMITTED;
openCryptoki: I could not find any check for CKA_DERIVE. They do check CKF_DERIVE against the feature flags of the mechanism and return CKR_MECHANISM_INVALID if the flag is not set (reference), i.e. if the mechanism does not support derivation, but this is not the same as checking CKA_DERIVE against the flags of the key.
illumos-gate (IllumOS being a fork of the discontinued OpenSolaris) also returns CKR_KEY_FUNCTION_NOT_PERMITTED in their soft-key implementation (reference):
/* Check to see if key object allows for derivation. */
if (!(basekey_p->bool_attr_mask & DERIVE_BOOL_ON)) {
rv = CKR_KEY_FUNCTION_NOT_PERMITTED;
goto clean_exit1;
}
Interestingly, in older version of their code they returned CKR_KEY_TYPE_INCONSISTENT instead, and then changed it to CKR_KEY_FUNCTION_NOT_PERMITTED in this commit. The relevant part of the commit message seems to be 6177650 Wrong error code returned when key does not allow requested operation. The ID refers to a ticket in the OpenSolaris bug tracker, which is no longer online. There is an archive of the bug tracker here, but it does not contain any information on this ticket, unfortunately.
Of these reference implementations, I would consider OpenSC to be the most authoritative, in terms of how widely they are used.
Conclusion
Based on the above considerations, I would consider CKR_KEY_FUNCTION_NOT_PERMITTED to be the appropriate return code for the scenario we are discussing. This is supported by the following arguments:
The specification explicitly acknowledges that the list of possible return code for each function might be incomplete. Therefore, CKR_KEY_FUNCTION_NOT_PERMITTED not being listed for C_DeriveKey is not a strong counter-argument.
The specification explicitly lists CKA_ENCRYPT as an example for when CKR_KEY_FUNCTION_NOT_PERMITTED is an appropriate return code. The attribute CKA_ENCRYPT is similar to CKA_DERIVE, so it seems plausible that the return code is also appropriate for CKA_DERIVE.
The specification of CKR_KEY_TYPE_INCONSISTENT suggest that it is about the relation between the mechanism and the key type, not about other key attributes.
OpenSC uses CKR_KEY_TYPE_INCONSISTENT for the scenario we are discussing, but also uses this return code for C_DecryptInit in the case that CKA_DECRYPT is not set, which goes against the example given in the specification of CKR_KEY_FUNCTION_NOT_PERMITTED.
OpenSolaris/IllumOS deliberately switched from CKR_KEY_TYPE_INCONSISTENT to CKR_KEY_FUNCTION_NOT_PERMITTED as the return code for the scenario we are discussing. This suggests they also considered the latter the more fitting return code.
I am trying to support the 'duplicate' command. It works fine for duplicating the top class:
tell application "SpellAnalysis" to duplicate level 1
This, however, crashes:
tell application "SpellAnalysis" to duplicate (get unit 1 of (get level 1))
I have provided index specifiers for both classes, where the outer container for 'unit' is 'level'. Oddly, I can specify a property of the unit class like this:
tell application "SpellAnalysis" to (get general rule of unit 1 of (get level 1))
The culprit seems to be that the 'objectsByEvaluatingSpecifier' always returns a null value when used within NSCloneCommand subclass, as well as the unit class' objectSpecifier method, where its needed.
I was finally able to support AppleScript 'duplicate' command. Although the normal way to support the command is by sub-classing 'NSCloneCommand', with this method, your direct parameter results in a specifier that specifies the containing object and not the direct object--as a special provision of the 'NSCloneCommand'. I suppose this is meant to facilitate the case when you would be duplicating an object belonging to a document, where the document class provides the means for creating new constituent objects. Unfortunately, in my case, my constituent objects take part in their own duplication and need to know their specifiers to do so. The solution was to support the 'duplicate' command by the optional technique of creating a custom 'duplicate' command within my application's suite that entailed subclassing the more general 'NSScriptCommand'. This alternative avoids any redirection of the specifier returned from the 'directParameter' method of the 'NSScriptCommand' class. I was able to work from there to derive all the child class-objects for cloning.
Ruby has this very interesting functionality in which when you create a class with 'Class.new' and assign it to a constant (uppercase), the language "magically" sets up the name of the class so it matches the constant.
# This is ruby code
MyRubyClass = Class.new(SuperClass)
puts MyRubyClass.name # "MyRubyClass"
It seems ruby "captures" the assignment and inserts sets the name on the anonymous class.
I'd like to know if there's a way to do something similar in Lua.
I've implemented my own class system, but for it to work I've got to specify the same name twice:
-- This is Lua code
MyLuaClass = class('MyLuaClass', SuperClass)
print(MyLuaClass.name) -- MyLuaClass
I'd like to get rid of that 'MyLuaClass' string. Is there any way to do this in Lua?
When assigning to global variables you can set a __newindex metamethod for the table of globals to catch assignments of class variables and do whatever is needed.
You can eliminate one of the mentions of MyLuaClass...
> function class(name,superclass) _G[name] = {superclass=superclass} end
> class('MyLuaClass',33)
> =MyLuaClass
table: 0x10010b900
> =MyLuaClass.superclass
33
>
Not really. Lua is not an object-orientated language. It can behave like one sometimes. But far from every time. Classes are not special values in Lua. A table has the value you put in it, no more. The best you can do is manually set the key in _G from the class function and eliminate having to take the return value.
I guess that if it REALLY, REALLY bothers you, you could use debug.traceback(), get a stack trace, find the calling file, and parse it to find the variable name. Then set that. But that's more than a little overkill.
With respect at least to Lua 5.2: You can capture assignments to A) the global table of a Lua State, as mentioned in a previous reply, and also B) to any other Lua Object whose __index and __newindex metamethods have been substituted (by replacing the metatable), this I can confirm as I'm currently using both these techniques to hook and redirect assignments made by Lua scripts to external C/C++ resource management.
There is a gotcha with regards to reading them back though, the trick is to NOT let the values be set in a Lua State.
As soon as they exist there, your hooks will fail to be called, so if you want to go down this path, you need to capture ALL get/set attempts, and NEVER store the values in a Lua State.