(warning, adjusted CC's and added netdev mailing list)


David Miller wrote:
From: [EMAIL PROTECTED]
Date: Wed, 26 Sep 2007 18:14:42 -0700

From: Yinghai Lu <[EMAIL PROTECTED]>

Signed-off-by: Yinghai Lu <[EMAIL PROTECTED]>
Cc: Christoph Lameter <[EMAIL PROTECTED]>
Cc: Andy Whitcroft <[EMAIL PROTECTED]>
Cc: Jeff Garzik <[EMAIL PROTECTED]>
Cc: Andi Kleen <[EMAIL PROTECTED]>
Cc: "David S. Miller" <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>

I'm not applying this, I'm still not convinced it is right.

The device of netdev->dev is a network subsystem pseudo device and
it's not a real I/O device at all.  It's there for creating the
class/net/name info under sysfs for the network device.

So pulling the NUMA node information out of there is completely

Agreed.


illogical even if you do add some ugly hack to propagate the NUMA
information from the I/O device parent into the device struct the
netdev has embedded in it.

I don't think it's an ugly hack at all. The following is the standard way to tell the net device your parent:

#define SET_NETDEV_DEV(net, pdev)       ((net)->dev.parent = (pdev))

so therefore reading the parent is the standard (only?) way to retrieve that same information.

Using IETF RFC language: Every net driver SHOULD have an associated struct device via SET_NETDEV_DEV(), even if it's another pseudo-device in the case where the net_device is not associated with real hardware.


However, that said, the overall /system/ employed here is a hack, because SET_NETDEV_DEV() does not actually adjust any reference counts or anything, for the associated net_device or associated struct device.

Al Viro pointed out problems related to this, ISTR, when someone tried to convert net drivers over to using the new devres stuff. That's why I haven't been merging the devres net driver conversions -- they exacerbate existing object lifetime-related problems.

        Jeff


-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to