Application specific VTY attributes

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.de
Wed Sep 23 15:48:23 UTC 2020


Hi 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>


More information about the OpenBSC mailing list