[LiSA-Devel] RFC: modificare CLI

[Radu Rendec]

In vederea urmatoarelor proiecte LiSA, trebuie puse la punct cateva
aspecte legate de CLI. Modificarile ar trebui facute inainte de a se mai
face extinderi pe structura actuala.

De modificari ma voi ocupa in principal eu. Orice ajutor este insa
binevenit :)

Ceea ce urmeaza are titlu de propunere pentru viitorul CLI-ului. Prin
urmare astept comentariile voastre (Ionut N este primul vizat) relativ
la ceea ce am scris acolo.

1. Rezolvarea specificarii interfetelor

1.1. Adaugarea flag-ului "ACCEPT_INCOMPLETE" pentru (struct cmd).state -
flag-ul trebuie sa accepte token-ul ca fiind valid la primul caracter
care nu se potriveste cu pattern-ul; urmatoarele caractere (inclusiv
primul care nu se potriveste cu pattern-ul) sunt considerate ca facand
parte din urmatorul token.

Exemplu: meniul "interface" contine in lista de subcomenzi "ethernet".
Pentru subcomanda "ethernet" este setat flag-ul, astfel incat daca
userul
scrie "eth1", atunci '1' este primul caracter care nu se potriveste; in
acest caz se considera "eth" ca token, iar '1' face parte din primul
argument.

Astfel se poate trata elegant validarea tuturor variantelor: "eth1",
"eth 1", "ethernet1", "ethernet 1" etc.

1.2 Adaugare tip interfata "netdev": pentru a pastra ideea de la Cisco
(in meniul "interface" apar tipuri de interfete) si in acelasi timp
compatibilitatea cu patch-ul de integrare cu Xen, inlocuim subcomanda de
tip "WORD" din meniul "interface" cu subcomanda "netdev", care accepta
ca subcomanda "WORD" (orice interfata).

Astfel dispare ambiguitatea pentru "interface eth1", respectiv daca
"eth1" reprezinta forma prescurtata de "ethernet 1" sau netdevice-ul
"eth1".

Comenzile "ethernet <n>" si "vlan <n>" construiesc in spate numele real
al netdevice-ului ("eth<n>" respectiv "vlan<n>") inainte de a face
apelul ioctl().

1.3. Adaugare in "struct cmd" handler pentru generare dinamica de
submeniu. Poate fi folosit pentru a implementa cat mai convenabil
submeniul ramurii "netdev": in loc de "WORD" se poate lua dinamic lista
de interfete ethernet din /proc/net/devices si genera un submeniu cu
acestea.

Facand teste, interfetele care nu sunt aplicabile pot fi filtrate,
generand lista in functie de context.

1.4. Apel ioctl() validare nume corect vlan: nu orice interfata care are
numele "vlan<n>" este o interfata vif LiSA. Se poate face o functie
ioctl() care testeaza daca este un vif valid, folosind membrul sw_port
din struct net_device.

2. Unificarea meniurilor "interface"

2.1. Modificarea prototipului sw_command_handler astfel incat sa
primeasca si o lista cu "argumentele" precedente (lista de token-i de pe
linia de comanda dinaintea comenzii pentru care se executa handlerul).

Parserul de comenzi trebuie modificat sa construiasca lista de argumente
precedente. Daca argumentele sunt in forma prescurtata (ex. "sh
int ...")
in lista trebuie sa apara argumentele in forma completa, astfel incat sa
poata fi identificate corect indiferent cum le scrie userul.

2.2. Renuntarea la meniuri (vectori de subcomenzi) separate pentru
comanda "interface". Se poate folosi un meniu unic, iar handlerul va
detecta contextul din care a fost apelat folosind 2.1. In functie de
context va executa comanda corecta.

2.3. Adaugarea flag-ului "HIDDEN" pentru (struct cmd).state - poate fi
folosit pentru:
* folosirea unui singur vector de comenzi comun pentru interfetele de
  tip switched si routed; comenzile care nu sunt aplicabile tipului de
  interfata sunt ascunse;
* unificarea comenzilor pentru interfetele de tip vlan si routed: toata
  partea de configurare adrese ip este identica, dar comenzile de cdp nu
  sunt aplicabile pentru interfetele vlan; comenzile cdp pot vi ascunse
  pentru interfetele vlan.

2.4. Adaugare in "struct cmd" a unui handler care sa fie apelat inaintea
iteratiilor prin submeniu (completion, inline help, validare). Acesta
permite de exemplu setarea flagului HIDDEN acolo unde este cazul.

Abordarea este posibila deoarece toate cli-urile sunt single-threaded,
prin urmare nu exista acces concurent pe vectorul de comenzi. Acesta
poate fi modificat in avans ori de cate ori este nevoie fara a afecta
functionarea altor componente.

3. Generarea surselor C pentru vectorii de struct cmd folosind fisiere
xml.

3.1. Formatul fisierului xml

<?xml version="1.0"?>
<root menu="...">
  <include>...</include>        Includere header (fisier .h)
  ...
  <include>...</include>
  <menu name="...">
    <command name="..." priv="...">
      <valid>...</valid>        Functie validare pattern
      <exec>...</exec>          Handler apelat pentru rulare comanda
      <pre>...</pre>            Handler descris la 2.4
      <dyn>...</dyn>            Handler descris la 1.3
      <flags>...</flags>        Flag-uri (RUNNABLE, HIDDEN etc.)
      <doc>...</doc>            Descrierea comenzii pentru inline help
      <menu [name="..."]>       Definitie inline submeniu
        <command ...>
          ...
        </command>
        ...
        <command ...>
          ...
        </command>
      </menu>
    </command>
    ...
    <command ...>
        ...
        <menu ref=""/>          Referire la un alt meniu folosind numele
    </command>
  </menu>
  ...
  <menu name="...">
    ...
  </menu>
</root>

Sugestie: pentru lizibilitate, imediat dupa fiecare tag "command" se
pune un comentariu cu calea (sirul de comenzi) de la radacina pana in
punctul respectiv.

3.2. Organizarea fisierelor
* fisierele .xml se gasesc in subdirectorul "menus" din userspace/cli;
* fisierele .xml au nume de tipul: main.xml, config.xml, config_if.xml,
  config_line.xml, interface.xml etc;

3.3. Propuneri parser
* php / xml parser (http://ro.php.net/manual/en/book.xml.php) - api
  simplu, nemodificat intre versiunea 4 si 5, nu necesita legarea cu
  vreo biblioteca externa (este built-in)
* c / libxml