This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.
Harald Welte hwelte at sysmocom.deSorry for the late response, On Wed, Sep 23, 2020 at 03:58:31PM +0200, Neels Hofmeyr wrote: > On Wed, Sep 23, 2020 at 05:40:39PM +0700, Vadim Yanitskiy wrote: > > struct cmd_node foo_node = { > > .usrattr = (1 << FOO_VTY_ATTR_RESTART_FULL), // (!) > > }; > > this way we could no longer see that a newly added command failed to set the > correct user attribute. i.e. I add a new DEFUN, I fail to remember setting > attributes, and thus it shows some attribute which is wrong. If each command > gets explicit attributes, errors like that are unlikely: If I add a DEFUN and > forget to set the right attribute, there will be no attribute, and a user > reading the vty reference will ask us to fix, without the need to try and fail > first. we could have a checker script that issues warnings, similar to the value_string checker? We could indeed also deprecate DEFUN (make it print a warning for now) while things are migrated to those with attributes... > libosmocore defined attrs would be useful. ACK. > I know that the VTY code disregards osmo_ completely, but I'd still favor > prepending OSMO_* to new enum values. I'm -as usual - in favor of consistency. So if the old code has no prefix, any additions should also not have prefixes. > btw, each and every osmo_fsm caller and now also each and every vty attribute > defining code defines a left-shift macro like > > #define S(x) (1 << (x)) > > it's a bit silly to repeat this definition all over the place. > Added to libosmocore, it would have to be called OSMO_S()... > makes everything longer. maybe nevermind, just thinking aloud. > } Yes, that is a known issue.. > > dexter wrote: > > > Maybe we could have some standard letters defined in libosmocore > > > for standard situations: > > > F = Full restart required > > > I = Applied Immediately > > > > ACK. We can also agree that generic (pre-defined) attributes use upper > > case letters, while the application specific ones use lower case? I like that approach > Then again, 'F' should mean the same thing in various osmo-* programs? yes. > But consider, having attributes of upper case and lower case of the same letter > could be somewhat confusing to users. Well, given that in iptables, lowercase are matches and uppercase are targets, I guess it's clear I don't share such a concern. But maybe it is confusing to Windows users who are taught for decades that there is no distinction between upper and lower case? I'm willing to accept that there is a concern. > libosmocore assigns letters, applications assign numbers and special > characters?? I would go for the other way around, as I would expect libosmocore to define fewer 'common' attributes, while applications may have more different flags. So as there are fewer numbers than lstters, I'd go for libosmocore=numbers. Please note that in the end it's not just libosmcoore, but also libosmogb, libosmo-abis, libosmo-sccp, ... Regards, Harald -- - Harald Welte <hwelte at sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte