NetworkManager/libnm-core/nm-setting-generic.c

63 lines
1.7 KiB
C
Raw Permalink Normal View History

/* SPDX-License-Identifier: LGPL-2.1+ */
/*
* Copyright (C) 2013 Red Hat, Inc.
*/
#include "nm-default.h"
#include "nm-setting-generic.h"
#include "nm-setting-private.h"
/**
* SECTION:nm-setting-generic
* @short_description: Describes connection properties for generic devices
*
* The #NMSettingGeneric object is a #NMSetting subclass that describes
* optional properties that apply to "generic" devices (ie, devices that
* NetworkManager does not specifically recognize).
*
* There are currently no properties on this object; it exists only to be
* the "connection type" setting on #NMConnections for generic devices.
**/
/*****************************************************************************/
typedef struct {
int dummy;
} NMSettingGenericPrivate;
G_DEFINE_TYPE(NMSettingGeneric, nm_setting_generic, NM_TYPE_SETTING)
#define NM_SETTING_GENERIC_GET_PRIVATE(o) \
(G_TYPE_INSTANCE_GET_PRIVATE((o), NM_TYPE_SETTING_GENERIC, NMSettingGenericPrivate))
/*****************************************************************************/
static void
nm_setting_generic_init(NMSettingGeneric *setting)
{}
/**
* nm_setting_generic_new:
*
* Creates a new #NMSettingGeneric object with default values.
*
* Returns: (transfer full): the new empty #NMSettingGeneric object
**/
NMSetting *
nm_setting_generic_new(void)
{
return g_object_new(NM_TYPE_SETTING_GENERIC, NULL);
}
static void
nm_setting_generic_class_init(NMSettingGenericClass *klass)
{
NMSettingClass *setting_class = NM_SETTING_CLASS(klass);
libnm: use NMMetaSettingInfo for tracking setting priority Previously, each (non abstract) NMSetting class had to register its name and priority via _nm_register_setting(). Note, that libnm-core.la already links against "nm-meta-setting.c", which also redundantly keeps track of the settings name and gtype as well. Re-use NMMetaSettingInfo also in libnm-core.la, to track this meta data. The goal is to get rid of private data structures that track meta data about NMSetting classes. In this case, "registered_settings" hash. Instead, we should have one place where all this meta data is tracked. This was, it is also accessible as internal API, which can be useful (for keyfile). Note that NMSettingClass has some overlap with NMMetaSettingInfo. One difference is, that NMMetaSettingInfo is const, while NMSettingClass is only initialized during the class_init() method. Appart from that, it's mostly a matter of taste, whether we attach meta data to NMSettingClass, to NMMetaSettingInfo, or to a static-array indexed by NMMetaSettingType. Note, that previously, _nm_register_setting() was private API. That means, no user could subclass a functioning NMSetting instance. The same is still true: NMMetaSettingInfo is internal API and users cannot access it to create their own NMSetting subclasses. But that is almost desired. libnm is not designed, to be extensible via subclassing, nor is it clear why that would be a useful thing to do. One day, we should remove the NMSetting and NMSettingClass definitions from public headers. Their only use is subclassing the types, which however does not work. While libnm-core was linking already against nm-meta-setting.c, nm_meta_setting_infos was unreferenced. So, this change increases the binary size of libnm and NetworkManager (1032 bytes). Note however that roughly the same information was previously allocated at runtime.
2018-07-27 14:08:14 +02:00
g_type_class_add_private(klass, sizeof(NMSettingGenericPrivate));
libnm: use NMMetaSettingInfo for tracking setting priority Previously, each (non abstract) NMSetting class had to register its name and priority via _nm_register_setting(). Note, that libnm-core.la already links against "nm-meta-setting.c", which also redundantly keeps track of the settings name and gtype as well. Re-use NMMetaSettingInfo also in libnm-core.la, to track this meta data. The goal is to get rid of private data structures that track meta data about NMSetting classes. In this case, "registered_settings" hash. Instead, we should have one place where all this meta data is tracked. This was, it is also accessible as internal API, which can be useful (for keyfile). Note that NMSettingClass has some overlap with NMMetaSettingInfo. One difference is, that NMMetaSettingInfo is const, while NMSettingClass is only initialized during the class_init() method. Appart from that, it's mostly a matter of taste, whether we attach meta data to NMSettingClass, to NMMetaSettingInfo, or to a static-array indexed by NMMetaSettingType. Note, that previously, _nm_register_setting() was private API. That means, no user could subclass a functioning NMSetting instance. The same is still true: NMMetaSettingInfo is internal API and users cannot access it to create their own NMSetting subclasses. But that is almost desired. libnm is not designed, to be extensible via subclassing, nor is it clear why that would be a useful thing to do. One day, we should remove the NMSetting and NMSettingClass definitions from public headers. Their only use is subclassing the types, which however does not work. While libnm-core was linking already against nm-meta-setting.c, nm_meta_setting_infos was unreferenced. So, this change increases the binary size of libnm and NetworkManager (1032 bytes). Note however that roughly the same information was previously allocated at runtime.
2018-07-27 14:08:14 +02:00
_nm_setting_class_commit(setting_class, NM_META_SETTING_TYPE_GENERIC);
}