Add basic dynamicstore wrapper

[faern]

Adding a formatter settings file. Same as we have everywhere else.

Depending on git version of core-foundations. Because it has a number of patches merged that I created to make some things easier/possible to implement in system configuration. Not sure when/if they will release an upgrade. But at this early stage of playing with system configuration it does not matter if we depend on a git version IMO.

Adding the base SCDynamicStore functionality. This version can get and set values in the store. Please audit this carefully for memory correctness. There are more features coming to this struct. But I wanted to keep it simple in first PR, to correctly audit the base of it.

I added a temporary bin, set_dns, that uses this new struct to read out the primary interface and set the DNS of it to 8.8.8.8 and 8.8.4.4 so this code can be tested and played with.

---

This change is 

[pronebird]

Reviewed 3 of 6 files at r1.
Review status: 3 of 6 files reviewed at latest revision, 1 unresolved discussion.

---

system-configuration/src/dynamic_store.rs, line 57 at r1 (raw file):

            let store_options = CFDictionary::from_CFType_pairs(&[
                (
                    CFString::wrap_under_create_rule(kSCDynamicStoreUseSessionKeys),

I thought you said that we cannot modify existing keys with kSCDynamocStoreUseSessionKeys flag.

---

Comments from Reviewable

[pronebird]

Review status: 3 of 6 files reviewed at latest revision, 2 unresolved discussions.

---

system-configuration/src/dynamic_store.rs, line 80 at r1 (raw file):
Be careful casting this to CFDictionaryRef.

According to docs SCDynamicStoreCopyValue returns CFPropertyListRef which can be a reference to any kind of value.

CFPropertyListRef can be a reference to any of the property list objects: CFData, CFString, CFArray, CFDictionary, CFDate, CFBoolean, and CFNumber

In order to check the returned type we have to get CFTypeID and compare it against known type ID, for example:

// is it CFDictionaryRef?
CFGetTypeID(dict_ref.as_concrete_TypeRef()) == CFDictionaryGetTypeID() 

// is it CFNumberRef?
CFGetTypeID(dict_ref.as_concrete_TypeRef()) == CFNumberGetTypeID();

---

Comments from Reviewable

[pronebird]

Review status: 3 of 6 files reviewed at latest revision, 3 unresolved discussions.

---

system-configuration/src/dynamic_store.rs, line 90 at r1 (raw file):

    /// Sets the value of the given key. Overwrites existing values.
    /// Returns `true` on success, false on failure.
    pub fn set<S: Into<CFString>>(&self, key: S, value: &CFDictionary) -> bool {

You should accept CFPropertyListRef here because depending on key you may be setting single boolean or date or entire dictionary.

---

Comments from Reviewable

[pronebird]

Reviewed 1 of 6 files at r1.
Review status: 4 of 6 files reviewed at latest revision, 3 unresolved discussions.

---

Comments from Reviewable

[pronebird]

Reviewed 2 of 6 files at r1.
Review status: all files reviewed at latest revision, 3 unresolved discussions.

---

Comments from Reviewable

[faern]

Review status: all files reviewed at latest revision, 3 unresolved discussions.

---

system-configuration/src/dynamic_store.rs, line 57 at r1 (raw file):

Previously, pronebird (Andrei Mihailov) wrote…

I thought you said that we cannot modify existing keys with kSCDynamocStoreUseSessionKeys flag.

We can't. And we likely won't use this constructor. But since I tried it I already had the code. So I did not see any reason to not include this special contructor. Since this will be a general OSS library it's good to cover more use cases when it does not cost us extra work.

---

system-configuration/src/dynamic_store.rs, line 80 at r1 (raw file):

Previously, pronebird (Andrei Mihailov) wrote…

Be careful casting this to CFDictionaryRef.

According to docs SCDynamicStoreCopyValue returns CFPropertyListRef which can be a reference to any kind of value.

CFPropertyListRef can be a reference to any of the property list objects: CFData, CFString, CFArray, CFDictionary, CFDate, CFBoolean, and CFNumber

In order to check the returned type we have to get CFTypeID and compare it against known type ID, for example:

// is it CFDictionaryRef?
CFGetTypeID(dict_ref.as_concrete_TypeRef()) == CFDictionaryGetTypeID() 

// is it CFNumberRef?
CFGetTypeID(dict_ref.as_concrete_TypeRef()) == CFNumberGetTypeID();

Ah. Thanks. Was not too sure about that assumption. I'll fix.

---

system-configuration/src/dynamic_store.rs, line 90 at r1 (raw file):

Previously, pronebird (Andrei Mihailov) wrote…

You should accept CFPropertyListRef here because depending on key you may be setting single boolean or date or entire dictionary.

I see! I was not aware of exactly which types were OK.

But since this wrapper should be safe I don't want to take the underlying *Ref value since that is unsafe.

I think I instead could take <V: TCFType<_>> so any CF type is accepted. And then internally I can at runtime check that it's one of the allowed types, if it's not I return with an error before doing the SCDynamicStoreSetValue` call.

---

Comments from Reviewable

[pronebird]

Review status: all files reviewed at latest revision, 1 unresolved discussion.

---

system-configuration/src/dynamic_store.rs, line 90 at r1 (raw file):

CFPropertyListRef can be a reference to any of the property list objects: CFData, CFString, CFArray, CFDictionary, CFDate, CFBoolean, and CFNumber.

I am not sure what happens if you pass any other CFType here though. It could reject the type or simply crash with exception.

---

Comments from Reviewable

[pronebird]

Review status: all files reviewed at latest revision, 1 unresolved discussion.

---

system-configuration/src/dynamic_store.rs, line 90 at r1 (raw file):

Previously, pronebird (Andrei Mihailov) wrote…

CFPropertyListRef can be a reference to any of the property list objects: CFData, CFString, CFArray, CFDictionary, CFDate, CFBoolean, and CFNumber.

I am not sure what happens if you pass any other CFType here though. It could reject the type or simply crash with exception.

*could reject the update

---

Comments from Reviewable

[pronebird]

Review status: all files reviewed at latest revision, 1 unresolved discussion.

---

system-configuration/src/dynamic_store.rs, line 90 at r1 (raw file):

Previously, pronebird (Andrei Mihailov) wrote…

*could reject the update

And yes indeed you could limit accepted types with generic or something or even add a trait to unite certain types.

---

Comments from Reviewable

[faern]

Review status: 3 of 6 files reviewed at latest revision, 2 unresolved discussions.

---

system-configuration-sys/Cargo.toml, line 14 at r1 (raw file):

[dependencies]
core-foundation = { git = "https://github.com/servo/core-foundation-rs", version = "0.4.4" }
core-foundation-sys = { git = "https://github.com/servo/core-foundation-rs", version = "0.4.4" }

Whoops. Should not depend on the higher level crate from a sys crate. We didn't actually use it, I probably just copy pasted the two dependencies to both crates.

---

system-configuration/src/dynamic_store.rs, line 90 at r1 (raw file):

Previously, pronebird (Andrei Mihailov) wrote…

And yes indeed you could limit accepted types with generic or something or even add a trait to unite certain types.

I got some stuff merged upstream in core-foundation which adds a CFPropertyList type we can use. It has a convenience method to cast it to one of the valid subtypes. It checks at runtime if the instance has the correct type, so downcast returns Noneif I have aCFPropertyListrepresenting aCFStringbut I try to cast it down to aCFBoolean` for example. See this PR for more information: servo/core-foundation-rs#131

The extra R parameter is a bit bulky, but is required since I need a generic for the trait CFPropertyListSubClass. I have a PR on core-foundation to simplify that, but it's not merged yet: servo/core-foundation-rs#132
If it becomes merged we can slightly simplify this a bit.

---

Comments from Reviewable

[pronebird]

Review status: 3 of 6 files reviewed at latest revision, 1 unresolved discussion.

---

system-configuration/src/dynamic_store.rs, line 90 at r1 (raw file):

Previously, faern (Linus Färnstrand) wrote…

I got some stuff merged upstream in core-foundation which adds a CFPropertyList type we can use. It has a convenience method to cast it to one of the valid subtypes. It checks at runtime if the instance has the correct type, so downcast returns Noneif I have aCFPropertyListrepresenting aCFStringbut I try to cast it down to aCFBoolean` for example. See this PR for more information: servo/core-foundation-rs#131

The extra R parameter is a bit bulky, but is required since I need a generic for the trait CFPropertyListSubClass. I have a PR on core-foundation to simplify that, but it's not merged yet: servo/core-foundation-rs#132
If it becomes merged we can slightly simplify this a bit.

Saw that! Good one!

---

Comments from Reviewable

[pronebird]

Reviewed 3 of 3 files at r2.
Review status: all files reviewed at latest revision, all discussions resolved.

---

Comments from Reviewable

[pronebird]

---

Review status: all files reviewed at latest revision, all discussions resolved, all commit checks successful.

---

Comments from Reviewable