On Wed, Mar 6, 2013 at 5:28 PM, <narendr...@dell.com> wrote: >> -----Original Message----- >> From: devel-boun...@lists.fedoraproject.org [mailto:devel- >> boun...@lists.fedoraproject.org] On Behalf Of Michal Schmidt >> Sent: Tuesday, March 05, 2013 10:22 PM >> To: devel@lists.fedoraproject.org >> Subject: Re: Proposed F19 Feature: systemd/udev Predictable Network >> Interface Names >> >> On 03/04/2013 04:01 PM, Matt Domsch wrote: >> > drivers/net/ethernet/sfc/siena.c: efx->net_dev->dev_id = >> EFX_OWORD_FIELD(reg, FRF_CZ_CS_PORT_NUM) - 1; >> >> I think sfc does not really *need* to set dev_id. >> Yes, these are multi-port cards, but the ports are on distinct PCI functions. >> > > I think setting of 'dev_id' by drivers/devices used in enterprise server > environment will be beneficial, not just for devices in which multiple ports > share a single PCI d/b/d/f("1 PCI d/b/d/f -> 2 ports"), also for multiport > devices with "1 PCI d/b/d/f -> 1 Port" mapping. The following scenarios > demonstrate the requirement/usefulness - > > 1. As the dev_id would indicate the physical port number used by a netdevice > and will be available to user space via sysfs, tools such as NetworkManager > could use the information to implement intelligent/smarter bonding of > netdevices. For example, when bonding netdevices coming from NIC partitions > (or SR-IOV VFs) which use the same physical port, in fault tolerance mode for > example, NM could inform the user that the netdevices being enslaved map > to/use the same physical port and bonding them may not have desired effect. > Dev_id would provide such information in a generic way. > > 2. biosdevname could possibly use 'dev_id' to determine the <port> part of > p<slot>p<port> eliminating the need to determine/enumerate port number as > pointed out here.
Using dev_id in the kernel for static and predictable per-device properties is fine, sure. Using dev_id with per-driver-global internal counters, or anything else that depends on any sort of probing or loading order is not; the range of dev_id must be local to every "instance" than can be separated and which the driver handles. Otherwise, I would not be surprised if the "creativity" of people would introduce new artificial and unpredictable enumerations in the kernel with that facility. :) Kay -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel