{"push_id":2764999951,"size":2,"distinct_size":2,"ref":"refs/heads/th/ethtool-options-rh1335409-1","head":"4f4763fa80eaef0f90e2c30b9e53612119d06595","before":"24463354cc17d01b24982f1011e2fe951523513c","commits":[{"sha":"f66a18062b92a5826e7e285ce085b7aaad9c243c","author":{"name":"Thomas Haller","email":"16e26612e4159990a6b3691e92592e691ff74132@redhat.com"},"message":"libnm: add generic-data interface to NMSetting\n\nlibnm's NMConnection is basically a dictionary of settings (\"a{sa{sv}}\"\non D-Bus), and NMSetting is basically a dictionary of variants (\"a{sv}\"\non D-Bus).\n\nAs part of libnm both types provide useful functionality to interpret\nprofiles as received from D-Bus, for example\n\n  - nm_connection_verify() can check for consistancy\n  - nm_connection_compare() can check for semantical equality\n    (unlike g_variant_equal() which just compare whether two\n    variants are literally equal).\n  - they provide introspection data so that it is easier to\n    understand which properties are available. Mostly they\n    do so via GObject properties.\n\nHowever, they have downsides:\n\n- they abstract too much. While a profile can be represented just as a\nGVariant, once it's converted to a NMConnection/NMSetting, the variant\nis no longer accessible (why?).\n\n- their native meta data is not sophisticated enough. Sure, there are\nGObject properties. But if this value is for example of type \"string\",\nwhich values are valid? How to generically convert a property to string\nand back? Which is something what nmcli, keyfile and ifcfg-rh do extensively.\n\n - For nmcli we need all of \"clients/common/nm-meta-setting-desc.c\" to handle this.\n\n - \"libnm-core/nm-keyfile.c\" is less generic that it should be, and needs\n   ParseInfoProperty extensively.\n\n - ifcfg-rh reader/writer is not generic at all, even for places where it\n   could be and doesn't have to follow initscripts API.\n\n - VPN handling of profile basically reduces everything to a dumb string\n   dictionary. The user experience with nmcli is very bad for VPN\n   profiles.\n\n- all supported properties must be GObject properties. See for example\nnm_setting_duplicate(), which only calls nm_setting_enumerate_values().\nThe latter can only iterate over GObject properties. That means,\npreviously, the only way to implement a property, is by adding it as a\nGObject property. For certain types, that is just too inflexible and\ncumbersome. That is why we have properties like NM_SETTING_VPN_DATA,\nNM_SETTING_BOND_OPTIONS, NM_SETTING_USER_DATA.\n\n- whenever we add a new property, or even a new NMSetting instance, we\nneed an incredible amount of code, just to implement this. Something\nthat should be as simple as having one general NMGenericSetting, which\nhas internally a vtable of calls for verify(), normalize(), compare(),\netc, is instead a set of 42 setting classes.\n\nThis patch doesn't solve these problems. It's just a small step of\nadding a more generic NMSetting implementation by staying closer to\nthe underlying GVariant.\n\nAs it is currently intended, only subclasses are supposed to set the\ngendata values. That means, for existing NMSetting types, nothing\nchanges, including their GVariant values will not be accessible via\nthis API. But new properties can make use of this API, to implement\npropeties that are easier to extend.\n\nThis is done, because I am about to add ethtool options. Ethtool has a\nlarge number of possible options, and preferably we will successively\nadd more and more. Adding and supporting a new ethtool options must\nbe low effort. That does not scale with the previous model.\n\nThis does not mean, that derived classes cannot (or shall not) add\nGObject properties or C functions for direct access. On the contrary,\nthese might be very important for a more convenient use. However,\nthe implementation of these GObject properties should be more generic\nand based on the underlying GVariant.","distinct":true,"url":"https://api.github.com/repos/freedesktop/NetworkManager/commits/f66a18062b92a5826e7e285ce085b7aaad9c243c"},{"sha":"4f4763fa80eaef0f90e2c30b9e53612119d06595","author":{"name":"Thomas Haller","email":"16e26612e4159990a6b3691e92592e691ff74132@redhat.com"},"message":"libnm, cli, ifcfg-rh: add NMSettingWired:offload-feature","distinct":true,"url":"https://api.github.com/repos/freedesktop/NetworkManager/commits/4f4763fa80eaef0f90e2c30b9e53612119d06595"}]}
{"actor":{"display_login":"fdo-mirror"}}