Re: [RFC PATCH 34/35] Add the Xen virtual network device driver.



The stuff in /proc could easily just be added attributes to the class_device kobject
of the net device (and then show up in sysfs).


+
+#define GRANT_INVALID_REF 0
+
+#define NET_TX_RING_SIZE __RING_SIZE((struct netif_tx_sring *)0, PAGE_SIZE)
+#define NET_RX_RING_SIZE __RING_SIZE((struct netif_rx_sring *)0, PAGE_SIZE)
+
+static inline void init_skb_shinfo(struct sk_buff *skb)
+{
+ atomic_set(&(skb_shinfo(skb)->dataref), 1);
+ skb_shinfo(skb)->nr_frags = 0;
+ skb_shinfo(skb)->frag_list = NULL;
+}
+

Could you use existing sk_buff_head instead of inventing your
own skb queue?

+struct netfront_info
+{
+ struct list_head list;
+ struct net_device *netdev;
+
+ struct net_device_stats stats;
+ unsigned int tx_full;
+
+ struct netif_tx_front_ring tx;
+ struct netif_rx_front_ring rx;
+
+ spinlock_t tx_lock;
+ spinlock_t rx_lock;
+
+ unsigned int handle;
+ unsigned int evtchn, irq;
+
+ /* What is the status of our connection to the remote backend? */
+#define BEST_CLOSED 0
+#define BEST_DISCONNECTED 1
+#define BEST_CONNECTED 2
+ unsigned int backend_state;
+
+ /* Is this interface open or closed (down or up)? */
+#define UST_CLOSED 0
+#define UST_OPEN 1
+ unsigned int user_state;
+
+ /* Receive-ring batched refills. */
+#define RX_MIN_TARGET 8
+#define RX_DFL_MIN_TARGET 64
+#define RX_MAX_TARGET NET_RX_RING_SIZE
+ int rx_min_target, rx_max_target, rx_target;
+ struct sk_buff_head rx_batch;
+
+ struct timer_list rx_refill_timer;
+
+ /*
+ * {tx,rx}_skbs store outstanding skbuffs. The first entry in each
+ * array is an index into a chain of free entries.
+ */
+ struct sk_buff *tx_skbs[NET_TX_RING_SIZE+1];
+ struct sk_buff *rx_skbs[NET_RX_RING_SIZE+1];
+
+ grant_ref_t gref_tx_head;
+ grant_ref_t grant_tx_ref[NET_TX_RING_SIZE + 1];
+ grant_ref_t gref_rx_head;
+ grant_ref_t grant_rx_ref[NET_TX_RING_SIZE + 1];
+
+ struct xenbus_device *xbdev;
+ int tx_ring_ref;
+ int rx_ring_ref;
+ u8 mac[ETH_ALEN];

Isn't mac address already stored in dev->dev_addr and/or dev->perm_addr?

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



Relevant Pages

  • [PATCH 4/6] AKT - min and max kobjects
    ... * through sysfs ... * The tunable is a kobject with 1 attributes: ... More majordomo info at http://vger.kernel.org/majordomo-info.html ... Please read the FAQ at http://www.tux.org/lkml/ ...
    (Linux-Kernel)
  • Re: [PATCHSET 3/4] sysfs: divorce sysfs from kobject and driver model
    ... but a kobject is still needed internally for the lifespan ... exactly - "internally" to the driver model (or drivers which ride ... To sysfs, it has no function other than being an opaque token. ... Removing kobject from the interface doesn't change anything about this. ...
    (Linux-Kernel)
  • Re: [PATCHSET 3/4] sysfs: divorce sysfs from kobject and driver model
    ... removal of kobject from sysfs interface is a logical and necessary ... I need to go back to what a "kobject" is to explain this. ... driver model to allow entities outside of driver model to use sysfs, ...
    (Linux-Kernel)
  • Re: [PATCHSET 3/4] sysfs: divorce sysfs from kobject and driver model
    ... The driver model serves as a unified layer for all devices managed by ... Changes in the kobject hierarchy are communicated to userspace ... sysfs is a virtual filesystem. ... interface from having to create it every time on their own. ...
    (Linux-Kernel)
  • Re: [PATCHSET 3/4] sysfs: divorce sysfs from kobject and driver model
    ... but a kobject is still needed internally for the lifespan ... exactly - "internally" to the driver model (or drivers which ride ... To sysfs, it has no function other than being an opaque token. ... Removing kobject from the interface doesn't change anything about this. ...
    (Linux-Kernel)