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>