2014-02-11 15 views
10

aufrufen Ich bin durch Linux-Netzwerk-Gerätetreiber Code und wollte wissen, ist es möglich, Geräteschicht Code aus Treibercode aufrufen.Ist es möglich, Geräte-Layer-Code von Treibercode in Linux Kernel

--- a/drivers/net/ethernet/realtek/8139too.c 
+++ b/drivers/net/ethernet/realtek/8139too.c 
@@ -1706,10 +1706,20 @@ static netdev_tx_t rtl8139_start_xmit (struct sk_buff *skb, 
    unsigned int entry; 
    unsigned int len = skb->len; 
    unsigned long flags; 
- 
+  int ret=0; 
    /* Calculate the next Tx descriptor entry. */ 
    entry = tp->cur_tx % NUM_TX_DESC; 

+ 
+  ret = dev_queue_xmit(skb); 
+ 
+  if (likely(ret == NET_XMIT_SUCCESS || ret == NET_XMIT_CN)) {} 
+ 
+   else { 
+    dev->stats.tx_dropped++; 
+ 
+  } 
+ 

In obigem Code, habe ich versucht dev_queque_xmit (SKB) zu nennen, die eine Schnittstelle zu Vorrichtungsschicht ist und angeschlossen mit Code Linux QoS.

Ich machte diese Änderungen in der Hoffnung, dass Paket-Drop aufgrund der Linux-Verkehrssteuerung von ifconfig Stats unter TX Drop-Byte-Feld erfasst wird, aber nicht sicher, diese Änderungen funktionieren würden?

Ist es möglich, Geräteschicht von Treiberschicht so zu rufen, wie ich es versucht habe?

+1

'dev_queue_xmit()' Routine exportiert nach Kernel für Gerätetreiber, ich denke, dass Ihr Code funktionieren sollte. –

+0

Dank Alexey für Ihre Kommentare, Mein Zweifel ist, Pakete auf höherer Ebene fallen gelassen werden noch in der unteren Schicht des Netzwerk-Stack erfasst werden können? –

+0

@Amit Singh Tomar, mit was gefangen? – osgx

Antwort

2

Wie, wenn dieser Code richtig funktionieren könnte, bezweifle ich so. Diese Änderung würde zu Problemen führen, wie:

dev_queue_xmit() 
     -> enqueue to QoS (I assume you mean Qdisc)  
      -> rtl8139_start_xmit() 
       -> dev_queue_xmit()  # creating a loop 

, derzeit keine Möglichkeit für „ifconfig“, um „Anzahl der Drop-Pakete (aufgrund QoS)“ wissen, denn „ifconfig“ Statistiken aus/proc/net lesen/dev, und diese Statistiken enthalten keine QoS-Statistiken, sondern nur den NIC-Treiber selbst.

Aber Sie können "Anzahl der Drop-Pakete (wegen QoS)" auf andere Weise kennenlernen. Im Kernel-Quellcode gibt es:

rtnl_register(PF_UNSPEC, RTM_GETQDISC, tc_get_qdisc, tc_dump_qdisc, NULL); # it fill "gnet_stats_queue", and there is a drop counter internally. 

, die Qdisc-Status, einschließlich Drop-Nummer wegen Überlastung Dump ist. Es ist eine Schnittstelle für Advanced-Benutzer-Level-Admin-Tool (nicht "ifconfig"), um detailliertere Informationen über Rtlink-Nachricht, zusätzlich zu "/ proc/net/dev" zu erhalten. Ich bin jedoch nicht sicher, was diese erweiterten Benutzer-Level-Admin-Tool sind (nicht vertraut mit ihnen). Vielleicht könnte "ip" -Befehl ??

+0

Danke @ Xzhao28 für Ihre Antwort. Ja, ich bekam die Kernel-Panik mit Änderungen, die ich in meiner Frage bemerkt hatte. Right-Fix wäre in net/sched und die Funktion, die du kennst, zeigt den inkrementierten Zähler in der "tc" -Befehlsausgabe. –

+0

@ xzxzhao28 gibt es eine Möglichkeit, rtnl_register() zu verwenden, um Qos-Paket in "ifconfig" -Ausgabe zu zeigen? –

+0

@Amit, es scheint keine einfache Möglichkeit, das zu tun, außer einige Code zu ändern. rtnl_register() ist ein Netlink-Callback im Kernel, und der "tc" -Befehl verwendet netlink socket, um diese Informationen abzurufen. Aber "ifconfig" lesen/proc/net/dev Eintrag, um seine Daten zu erhalten. Also 3 Wege: #a. modifiziere den Kernel, um die Statistiken in/proc/net/dev hinzuzufügen, also könnte "ifconfig" es bekommen. #b. modifiziere "ifconfig", um auch netlink socket wie "tc" zu verwenden. #c. Schreiben Sie ein Skript-Dienstprogramm, um die Befehlsausgabe "ifconfig" und "tc" zu integrieren. Ich denke, #c ist bevorzugt, da es keine Notwendigkeit gibt, den Kernel zu modifizieren oder "ifconfig" intern. – xzhao28