[LiSA-Devel] RFC: modificare CLI

[Radu Rendec]

On Mon, 2008-10-20 at 23:03 +0300, Ionut Nicu wrote:
> Am mai reflectat nitel si revin cu cateva idei in plus fata de ce am vb
> in weekend pe ym ...
>
> Partea proasta cu interfetele in linux e ca pot fi redenumite cum vrei
> tu (de ex: ip link set dev DEVICE name NEWNAME), deci nu cred ca are
> sens sa ne chinuim cu meniul "ethernet" sau "vlan" din care sa avem
> submeniu indecsii de interfete eth/vlan. 

Nu cred ca merita sa ne chinuim sa parsam lista de netdevice-uri ca sa
vedem care sunt numerele valide. Pentru compatibilitate, am putea sa le
lasam acolo, cu niste limite de bun simt (ex 1-4094 pt vlan-uri, 1-31
pentru ethernet).

> Poate mai bine facem comenzi (ioctl) care intorc lista de interfete
> adaugate in switch sau lista de interfete virtuale de tip vlan.

Nu sunt 100% sigur, dar cred ca avem deja ceva de genul asta pentru ca e
nevoie la build-area configuratiei curente. Pe de alta parte comenzile
"interface ... " din meniul de config nu se refera neaparat la interfete
deja existente in switch, pot fi folosite si ca sa adaugi alte interfete
(de unde si ideea cu luat lista cu toate netdevice-urile).

> Parerea mea e ca nu e musai sa fim 100% compliant cu Cisco dpdv
> structura meniuri la partea de interfete. Noi fiind pe linux lucram cu
> net_device-uri.

Tocmai de-aia mi-a venit ideea cu tipul de interfata "netdevice". Daca
cineva tine mortis, sigur ca poate schimba numele interfetelor si atunci
nu are decat sa faca referire cu "interface netdevice ...", dar in
general numele sunt standard: eth, vlan, tun, etc.

Cei de la zebra (quagga) au ales sa nu fie 100% compliant cu meniurile
de Cisco si mereu imi prind urechile cand incerc sa-l folosesc; mi-ar
placea sa nu facem la fel ca ei ;)

> > 3. Generarea surselor C pentru vectorii de struct cmd folosind fisiere
> > xml.
>
> Votez pentru varianta limbaj de scripting.
> 
> Primul gand care m-a lovit: oare n-avem nevoie si de transformarea
> inversa (parsare cod C si generare xml)? Asta ca sa importam ce avem
> acum ...

Parerea mea ca nu, pentru ca daca facem redesign la parser si adaugam
parametri / flag-uri noi, oricum va trebui sa le revizuim. In plus, Alex
s-a aratat interesat sa ne ajute la baut... a... reimplementat meniurile
(aka sa vina si el pe-acolo cand facem LiSA weekend).

> Alta chestie care a inceput sa ma chinuie de cand ti-am citit mesajul...
> daca abordam ideea cu xml-ul... vom avea referiri din xml la simboluri
> de prin sursele C ...
>  
> Oare nu e mai greu pt un developer sa gestioneze chestia asta decat sa
> editeze direct sursele C? Ar merita sa facem un tool (mai mult sau mai
> putin grafic) de editat meniuri care sa justifice migrarea asta spre
> xml?

Probabil ca nu vom face tool-ul, asa ca, intr-adevar, devine discutabil
daca ne ajuta xml-ul. Ideea era doar de a avea o organizare mai aproape
de ideea de meniu (i.e. arborescenta vs. flat + referinte). Pe mine ma
cam enerva la varianta direct in C ca aveam relativ multi vectori din
aia de structuri de dimensiune mica si trebuia sa cauti mult prin fiser
ca sa te prinzi care e parintele cui. Ramane sa mai dezbatem pe tema
asta.

Radu