Das ist eigentlich gar nicht soo schwer nachzuvollziehen. Wenn der cpmac-Treiber ein Netdevice registriert (cpmac_register_device in cpmac_eth.c), muss er in der Datenstruktur, die er dem Kernel übergibt auch ein paar Callbacks definieren, u.a. auch nen ioctl-Handler, genau: cpmaceth_ioctl in selbiger Datei.
Die "normalen" ioctls werden üblicherweise von dem Handler an den Standard-Handler weitergereicht, oder selber behandelt (ungefähr wie das Überladen bei objektorientierter Programmierung), die "privaten" ioctl macht er natürlich gleich selber.
Ups: ich seh grad, dass in dieser Fkt. der Hase begraben liegen könnte: dort werden nur zwei private weiter runtergereicht, und zwar die beiden, die ich nun genau nicht nehme(n kann).
Aber erstmal weiter im Kontext: weiter unten kommt irgendwann cpmac_main_ioctl aus der cpmac_main.c, die dispatched weiter an cpphy_if_control_req, die dann entsprechende adm_... calls macht, was wiederum den Switch programmiert.
Ich glaube, AVM hat bei den ioctls ne alte und ne neuere, abstrakteere Variante. Über die neuere Variante kann man nur VLANs für/über das WAN-Interface konfigurieren, vermutlich für VDSL?!
Du kannst ja in der cpmaceth_ioctl mal noch die fettgedruckten Zeilen reinschieben:
Code:
switch(cmd) {
case SIOCGMIIPHY:
case SIOCGMIIREG:
case SIOCSMIIREG:
case AVM_CPMAC_IOCTL_SET_CONFIG_N:
case AVM_CPMAC_IOCTL_GET_CONFIG_N:
[B]case AVM_CPMAC_IOCTL_INFO:
case AVM_CPMAC_IOCTL_GENERIC:[/B]
if (real_dev->do_ioctl && netif_device_present(real_dev))
err = real_dev->do_ioctl(real_dev, &ifrr, cmd);
break;
Dann sollte zumindest der info-Paramter gehen...
