Draft: Add VFS support for kmod (and PMU)
Add a VFS to interact with the lisa kmod and configure it dynamically.
Merge request reports
Activity
- lisa/_assets/kmodules/lisa/configs.c 0 → 100644
82 * Feature was enabled, and de-activating this config 83 * disabled the feature. 84 */ 85 if (feature->__explicitly_enabled && !cfg->activated) 86 deinit_single_features(feature->name); 87 continue; 88 } 89 90 if (cfg->activated) { 91 /* 92 * Feature was enabled. By default, de-init before re-init the feature 93 * to catch potential modifications. 94 */ 95 if (feature->__explicitly_enabled) 96 deinit_single_features(feature->name); 97 init_single_feature(feature->name); - Comment on lines +95 to +97
changed this line in version 2 of the diff
By Pierre Gondois on 2024-02-27T11:55:29
- lisa/_assets/kmodules/lisa/configs.c 0 → 100644
37 if (new_value) 38 ret = feature_param_remove_config_common(entry); 39 else 40 ret = feature_param_merge_common(entry); 41 if (ret) { 42 pr_err("Could not rollback config values\n"); 43 return ret; 44 } 45 } 46 } 47 48 return ret; 49 } 50 51 static inline 52 bool is_feature_set(char *name) changed this line in version 8 of the diff
By Pierre Gondois on 2024-06-28T13:52:28
- Resolved by Congregate Migrate
- lisa/_assets/kmodules/lisa/feature_params.c 0 → 100644
195 // feature_param type handlers 196 ///////////////////////////////////// 197 198 static int 199 feature_param_set_common(struct feature_param_entry *entry, void *data) 200 { 201 struct feature_param_entry_value *val; 202 int ret = 0; 203 204 switch (entry->param->mode) { 205 case FT_PARAM_MODE_SINGLE: 206 /* Single parameter, replace the pre-existing value. */ 207 /* 208 * TODO This might not be a good idea. The value is replaced 209 * even when the user thinks the value is appended. 210 * I.e. 'echo 1 >> file' will replace the pre-existing value. changed this line in version 2 of the diff
By Pierre Gondois on 2024-02-27T11:55:30
- Resolved by Congregate Migrate
- lisa/_assets/kmodules/lisa/feature_params.h 0 → 100644
75 * different configs. The resulting value is a set of all the 76 * values of the different configs. 77 */ 78 FT_PARAM_MODE_SET = 1, 79 }; 80 81 enum feature_param_type { 82 /* Standard parameter. */ 83 FT_PARAM_TYPE_STD = 0, 84 /* Specific to the 'lisa_features_param' parameter handling. */ 85 FT_PARAM_TYPE_AVAILABLE_FT, 86 }; 87 88 struct feature_param { 89 const char *name; 90 enum feature_param_mode mode; This shouldn't be an enum. Instead the functions to manipulate the param should be in feature_param_ops so they can be changed as needed for each user. The generic code must be completely agnostic on the format of the value itself, i.e. we can't have the generic code know anything specific about a "set" value vs a scalar. Anything the generic code can have access to is a set of operations.
changed this line in version 2 of the diff
By Pierre Gondois on 2024-02-27T11:55:31
- Resolved by Congregate Migrate
- Resolved by Congregate Migrate
- Resolved by Congregate Migrate
- Resolved by Congregate Migrate
222 int deinit_single_features(char *selected); 223 224 /** 225 * find_feature() - Find the (struct feature) matching the input name. 226 * @name: Name of the feature to find. 227 * 228 * Return: (struct feature*) matching the input name if success. 229 * NULL otherwise. 230 */ 231 struct feature *find_feature(char *name); 232 233 /** 234 * find_feature_param() - Find the (struct feature_param) of a feature 235 * matching the input name. 236 * @name: Name of the feature to find. 237 * @feature: Feature to search the (struct feature_param) from. changed this line in version 2 of the diff
By Pierre Gondois on 2024-02-27T11:55:33
- Resolved by Congregate Migrate
- Resolved by Congregate Migrate
- Resolved by Congregate Migrate
- Resolved by Congregate Migrate
137 149 int __placeholder_deinit(struct feature *feature) { 138 150 return 0; 139 151 } 152 153 struct feature *find_feature(char *name) changed this line in version 2 of the diff
By Pierre Gondois on 2024-02-27T11:55:36
- Resolved by Congregate Migrate
- lisa/_assets/kmodules/lisa/feature_params.h 0 → 100644
138 #define PARAM_SINGLE(name, perms, param_type, feature) \ 139 __PARAM(name, FT_PARAM_MODE_SINGLE, FT_PARAM_TYPE_STD, perms, param_type, __EVENT_FEATURE(feature)) 140 #define PARAM_SET(name, perms, param_type, feature) \ 141 __PARAM(name, FT_PARAM_MODE_SET, FT_PARAM_TYPE_STD, perms, param_type, __EVENT_FEATURE(feature)) 142 143 #define FEATURE_PARAMS(...) \ 144 .params = (struct feature_param* []){__VA_ARGS__, NULL} \ 145 146 #define EXPAND(...) __VA_ARGS__ 147 #define DEFINE_FEATURE_PARAMS(...) EXPAND(__VA_ARGS__) 148 149 #define for_each_feature_param(param, pparam, feature) \ 150 if (feature->params) \ 151 for (pparam = feature->params, param = *pparam; param != NULL; pparam++, param = *pparam) 152 153 #define feature_param_entry_print(param, val) { \ As useful as it is, it might be better to make it a 'debug' option or to switch
pr_errtopr_debugat least, I think. Failed attempt to set given parameter should be advertised throughwritesyscall, and that should suffice. Also - why not making it an inline function ? With macro it would be good to make sure it's parameters are safely used - as of use in brackets ....By Beata Michalska on 2024-02-15T15:41:05
This macro is being used to report details about a failure upon an attempt to activate given config: so upon writing to dedicated node (lisa_activate_write). It should be sufficient to report an error through fs write function (lisa_activate_write), and potentially leave this functionality for debug version only (?) Also at one point it has been considered to create a dedicated node per feature reporting last encountered error which could be used instead.
By Beata Michalska on 2024-02-25T16:34:04
changed this line in version 2 of the diff
By Pierre Gondois on 2024-02-27T11:55:37
- Resolved by Congregate Migrate