{"push_id":2758440169,"size":8,"distinct_size":8,"ref":"refs/heads/th/ethtool-options-rh1335409-1","head":"65f7c09f2685cc490ed54e8d7b401c79c71336f4","before":"b2f790fb5f55241bd913a6b02fa2c8776a891fcd","commits":[{"sha":"815fe56d20eaeac19ad17051541e4f54ed8b284f","author":{"name":"Thomas Haller","email":"16e26612e4159990a6b3691e92592e691ff74132@redhat.com"},"message":"libnm: use NMMetaSettingInfo for tracking setting priority\n\nPreviously, each (non abstract) NMSetting class had to register\nits name and priority via _nm_register_setting().\n\nNote, that libnm-core.la already links against \"nm-meta-setting.c\",\nwhich also redundantly keeps track of the settings name and gtype.\n\nLet NMMetaSettingInfo also track the setting priority and stronger\nglue NMSetting(Class) to its NMMetaSettingInfo.\n\nThis change has the following benefits:\n\n- the main benefit is that lookup of the meta data from a NMSetting instance,\n  from a NM_TYPE_SETTING or from a NMSettingClass, is now mostly just following\n  some pointers. Previously, it always required a hash table lookup.\n\n- it reduces duplication. The setting-name is no longer tracked twice,\n  but only in the NMMetaSettingInfo. Also, it moves the setting priority\n  into NMMetaSettingInfo, it fits there well.\n\nNote, that previously, _nm_register_setting() was private API. That\nmeans, no user could subclass a working NMSetting instance. The same\nis still true: NMMetaSettingInfo is internal API and users cannot access\nit to create their own NMSetting subclasses. But that is almost desired.\nlibnm is not designed, to be extensible via subclassing, nor is it\nclear why that would be a useful thing to do. One day, we should remove\nthe NMSetting and NMSettingClass definitions from public headers. Their\nonly use is subclassing the types, which however does not work.\n\nWhile libnm-core was linking already against nm-meta-setting.c,\nnm_meta_setting_infos was unreferenced. So, this change increases\nthe binary size of libnm and NetworkManager (1032 bytes). Note however\nthat roughly the same information was previously allocated at runtime.","distinct":true,"url":"https://api.github.com/repos/freedesktop/NetworkManager/commits/815fe56d20eaeac19ad17051541e4f54ed8b284f"},{"sha":"e77dba380be10b10e2787e2537e14715d242ff1b","author":{"name":"Thomas Haller","email":"16e26612e4159990a6b3691e92592e691ff74132@redhat.com"},"message":"shared: use binary search in nm_meta_setting_infos_by_name()\n\nnm_meta_setting_infos_by_name() did a naive search by name by\niterating over all 42 setting types.\n\nReorder nm_meta_setting_infos array, and use binary search instead.","distinct":true,"url":"https://api.github.com/repos/freedesktop/NetworkManager/commits/e77dba380be10b10e2787e2537e14715d242ff1b"},{"sha":"00f987232dd36d9ab8f982ef765326261765a4ae","author":{"name":"Thomas Haller","email":"16e26612e4159990a6b3691e92592e691ff74132@redhat.com"},"message":"libnm/keyfile: use NMMetaSettingInfo for indexing keyfile vtable\n\nWe have NMMetaSettingType enum, which is an enum of all setting types.\nWe also have an efficient way to get the enum (and its NMMetaSettingInfo)\nfrom an NMSetting, setting-name and GType.\n\nNo longer maintain the vtable for keyfile by \"setting-name\". Instead,\nindex it by NMMetaSettingType enum.\n\nThat way, we get efficient lookup, and don't need to duplicate the\nfunctionality of finding the vtable entry for a setting.","distinct":true,"url":"https://api.github.com/repos/freedesktop/NetworkManager/commits/00f987232dd36d9ab8f982ef765326261765a4ae"},{"sha":"0facc856ce35ec92bb888352b482a610267389da","author":{"name":"Thomas Haller","email":"16e26612e4159990a6b3691e92592e691ff74132@redhat.com"},"message":"libnm-core/trivial: move code","distinct":true,"url":"https://api.github.com/repos/freedesktop/NetworkManager/commits/0facc856ce35ec92bb888352b482a610267389da"},{"sha":"4f883ac202c2bc36aa039c102a1f422ea24cf54f","author":{"name":"Thomas Haller","email":"16e26612e4159990a6b3691e92592e691ff74132@redhat.com"},"message":"libnm: rework setting metadata for property handling\n\nNMSetting internally already tracked a list of all proper GObject properties\nand D-Bus-only properties.\n\nRework the tracking of the list, so that:\n\n- instead of attaching the data to the GType of the setting via\n  g_type_set_qdata(), it is tracked in a static array indexed by\n  NMMetaSettingType. This allows to find the setting-data by simple\n  pointer arithmetic, instead of taking a look and iterating (like\n  g_type_set_qdata() does).\n\n  Note, that this is still thread safe, because the static table entry is\n  initialized in the class-init function with _nm_setting_class_commit().\n  And it only accessed by following a NMSettingClass instance, thus\n  the class constructor already ran (maybe not for all setting classes,\n  but for the particular one that we look up).\n\n  I think this makes initialization of the metadata simpler to\n  understand.\n  Previously, in a first phase each class would attach the metadata\n  to the GType as setting_property_overrides_quark(). Then during\n  nm_setting_class_ensure_properties() it would merge them and\n  set as setting_properties_quark(). Now, during the first phase,\n  we only incrementally build a properties_override GArray, which\n  we finally hand over during nm_setting_class_commit().\n\n- sort the property infos by name and do binary search.\n\nAlso expose this meta data types as internal API in nm-setting-private.h.\nWhile not accessed yet, it can prove beneficial, to have direct (internal)\naccess to these structures.\n\nAlso, rename NMSettingProperty to NMSettInfoProperty to use a distinct\nnaming scheme. We already have 43 subclasses of NMSetting that are called\nNMSetting*. Likewise, NMMetaSetting* is heavily used already. So, choose a\nnew, distinct name.","distinct":true,"url":"https://api.github.com/repos/freedesktop/NetworkManager/commits/4f883ac202c2bc36aa039c102a1f422ea24cf54f"},{"sha":"3e8aeeacb5f72d4556fd196c1e7d17dfb7aa1770","author":{"name":"Thomas Haller","email":"16e26612e4159990a6b3691e92592e691ff74132@redhat.com"},"message":"libnm: minor rework checking property flags in _nm_setting_to_dbus()\n\nProperties that are backed by a GObject property are fundamentally\ndifferent.\n\nI think it's clearer to rework the check, to first check whether\nwe have a param_spec, and then implement different checks.","distinct":true,"url":"https://api.github.com/repos/freedesktop/NetworkManager/commits/3e8aeeacb5f72d4556fd196c1e7d17dfb7aa1770"},{"sha":"069318efd299a6ac9f0a9580243a09063647df0a","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 they both provide useful functionality for interpreting\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 dump string\n   dictionary. The user experience with nmcli is very bad for VPN\n   profiles.\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.\n\nThis patch doesn't solve these problems. It's just a small step of\nmaking NMSetting more generic. By exposing the GVariant values directly.\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,\nimplementing them should be possible more generically.","distinct":true,"url":"https://api.github.com/repos/freedesktop/NetworkManager/commits/069318efd299a6ac9f0a9580243a09063647df0a"},{"sha":"65f7c09f2685cc490ed54e8d7b401c79c71336f4","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/65f7c09f2685cc490ed54e8d7b401c79c71336f4"}]}
{"actor":{"display_login":"fdo-mirror"}}