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/.
Vadim Yanitskiy vyanitskiy at sysmocom.deHi Neels, On 9/23/20 8:58 PM, Neels Hofmeyr wrote: > libosmocore defined attrs would be useful. That would also require > some _VTY_ATTR_LAST enum value so that programs can add own attributes > that don't overlap. it needs to be clarified that we have two kinds of attributes: global (the ones defined in libosmocore, like CMD_ATTR_DEPRECATED) and application specific. Both are stored in separate bit-masks, not together. So there can be no overlap between the flag values. My proposal is to add CMD_ATTR_APPLY_{FULL_RESTART,IMMEDIATE} as global attributes, and still reserve 32 bits for application specific ones. > I know that the VTY code disregards osmo_ completely, but I'd still > favor prepending OSMO_* to new enum values. ACK, makes sense. We can also prepend 'OSMO_' to the existing symbols and add backwards-compatibility defines. Fortunately, only two attributes exist at the moment: CMD_ATTR_{DEPRECATED,HIDDEN}. > 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. I don't think it's a big deal to add a one-liner define. AFAIR, Max tried to get such macros merged to libosmocore, but his patch was rejected. > My opinion is not strong here. > > I guess the argument is that if we want to add a letter to libosmocore > later, we have to check each and every osmo-* program to avoid > collisions? > > ... > > libosmocore assigns letters, applications assign numbers and special > characters?? As I already mentioned, the attribute values themselves do not overlap, but if we assign flag letters to the globally defined attributes, then there is a chance that the letters would overlap. What I also forgot to point out is that we can have up to 8 global attributes and up to 32 application specific attributes, because: struct cmd_element { // ... unsigned char attr; /*!< Command attributes (global) */ unsigned int usrattr; /*!< Command attributes (program specific)*/ }; Given that we're not going to have more than 8 global attributes, and not going to assign anything to both CMD_ATTR_{DEPRECATED,HIDDEN}, I think reserving something like '*' and '!' would be enough. Best regards, Vadim. -- - Vadim Yanitskiy <vyanitskiy 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20200923/fd1bacb5/attachment.bin>