Ano, patrně se na ten hnijící kód se zcela zcestným designed (viz "rozhraní" ethX.Y pro další IP adresy na tom samém rozhraní) už nechce nikdo ani podívat. Vůbec se nedivím.
Ono vubec nejde o chyby a syntax. Hlavni technicky rozdil mezi ifconfig a ip je v tom, ze ifconfig pouziva 'tradicni' API (pomoci SIOCGIFxxx ioctl() operaci), zatimco ip pouziva API zalozene na Netlinku.
Nove funkce ve starem API vubec nejsou dostupne, takze by to znamenalo cely ifconfig stejne prepsat na Netlink. Coz se vlastne udelalo, akorat se zvolila nova syntax, ktera je uniformni a nezatizena minulosti, a vysledek se jmenuje ip.
Popravdě právě netlink (respektvice spíš rtnetlink), je na celém ip největší šílenost, která mi nepřipadá jako vhodné systémové řešení, narozdíl od standardního ioctl. Navíc není rtnetlink v podstatě vůbec z dokumentovaný. Manuálová stránka rozhodně nestačí k jeho použití. Takže kdo chce toto api použít jinak než skrze utilitu ip, tak si musí přečíst celé zdrojáky ip a navíc ještě odpovídající kód z kernelu, kde je dobré připomenout, že toto api se stále ještě mění.
Toto je také nejspíš důvod, proč se někdo nesebral a nenapsal sadu utilit se stejnou funkčností, ale jinou syntaxí, nebo nerozšířil funkce ifconfig, route atd.. Jakkoli to totiž vypadá triviálně, tak se stačí podívat do kódu ip a zjistíte, že je to hotové peklo, kde je parser argumentů přímo generuje paket pro rtnetlink, jehož podoba je známa jen autorům ip.
No, jako vyvojar software pouzivajici primo rtnetlink bych k tomu neco dodal:
1) Dokumentace k rtnetlink je malo jako u vetsiny linuxoveho API, relativne k ostatnim jde ale o nadprumer. Je tu nekolik manualovych stranek, pomerne obsahle RFC 3549 a hlavickove soubory, drive nebo pozdeji clovek ale stejne sahne ke zdrojakum jadra. Nejde ani tak o konretni API (to je vcelku primocare), jako o chovani linuxoveho sitoveho stacku.
2) Ony ioctl bych neoznacoval za standardni rozhrani, pokud vim POSIX ani SUS je nedefinuji, spise se jedna o tradicni rozhrani. V Linuxu nejsou dokumentovany o moc lepe nez rtnetlnk. Jejich feature-set je beznadejne zastaraly a navic nejsou dobre rozsiritelne narozdil od rtnetlinku, ktery pouziva TLV model zprav.
3) Na BSD-variantach take nemaji tyto ioctl jako nativni rozhrani, ale pouzivaji message-based API pripominajici netlink.
Zdrojaky jsou v OSS mozna vyvojarska dokumentace. Rozhodne ne dokumentace pro adminy/usery!!! To je to co me na ekosystemu GNU/ Linuxu velmi vytaci. Neni dokumentacni kazen any u takovych dulezitych komponent jako ip utils.
V momente kdy resim pruser tak posledni vec co bych delal je studovat zdrojaky jadra a nejake api. Bohuzel u linuxovych progrosu jde hodne videt ze v podstate toho moc nevi o unixove filosofii a nedokumentace toolu nebo jen kratky neaktualni canc se stal standardem.
Muj i predchozi post se tykal dokumentace API, nikoliv dokumentace toolu. Co se tyce kvality dokumentace toolu, tak zrovna utilita ip je dokumentovana IMHO docela dobre, manuaove stranky k ip jsou srovnatelne s FreeBSD ifconfig(8) a podstatne lepsi nez FreeBSD route(8).
