Application specific VTY attributes

[Neels Hofmeyr]

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.

> dexter wrote:
> > I just wonder if there could be a VTY_ATTR_RESTART_FULL predefined in
> > libosmore. Almost any of the osmo program will need it. Maybe also an
> > VTY_ATTR_RESTART_IMMEDIATE?
> 
> ACK.  I think they could be even moved to generic attributes:
> 
>   /*! Attributes (flags) for \ref cmd_element */
>   enum {
>     CMD_ATTR_DEPRECATED          = (1 << 0),
>     CMD_ATTR_HIDDEN              = (1 << 1),
>     CMD_ATTR_APPLY_IMMEDIATE     = (1 << 2),
>     CMD_ATTR_APPLY_FULL_RESTART  = (1 << 3),
>   };

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.

Not so sure about these CMD attributes including the left shift. It would
duplicate things, because we do need a plain integer enum to trivially hit the
right attribute indexes. See also osmo_fsm state and event values.

I know that the VTY code disregards osmo_ completely, but I'd still favor
prepending OSMO_* to new enum values.

{
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.
}

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

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?

I think the effort to do this explicitly is minor, so we can do it like cmdline
options: each program assigns its own letters completely?
Then again, 'F' should mean the same thing in various osmo-* programs?

But consider, having attributes of upper case and lower case of the same letter
could be somewhat confusing to users. Might as well just use numbers, like for
additives on a fast food menu...

libosmocore assigns letters, applications assign numbers and special
characters??

~N
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20200923/c483844e/attachment.bin>