* Re: [PATCH] Use firmware provided index to register a network
From: Greg KH @ 2010-09-23 16:33 UTC (permalink / raw)
To: Narendra_K
Cc: netdev, linux-hotplug, linux-pci, Matt_Domsch, Charles_Rose,
Jordan_Hargrave, Vijay_Nijhawan
In-Reply-To: <EDA0A4495861324DA2618B4C45DCB3EE6A0AFD@blrx3m08.blr.amer.dell.com>
On Thu, Sep 23, 2010 at 09:20:57PM +0530, Narendra_K@Dell.com wrote:
> > Now trying to change the kernel namespace itself seems like a bad hack
> > around this fact.
> >
>
> The patch does not change the existing kernel name space.
You are "reordering it", right?
> It adheres to the existing ethN name space with IFNAMSIZ length
> requirements. The patch only makes sure that eth0 always corresponds
> to what is labeled as 'Gb1' on server chassis, on systems where SMBIOS
> type 41 record is available. And removes the need for any renames for
> the interfaces which have a firmware index assigned by system
> firmware, as the very first name assigned by the kernel will be as
> expected and deterministic.
And on systems with buggy firmware, what is going to happen here? And
yes, there will be buggy BIOS tables, we can guarantee that, as this is
not something that Windows supports, right?
You are also complicating the logic for 99% of the world that will never
use this feature. But I'll leave that up to the netdev developers to
decide, it's their code to maintain over time, not mine :)
thanks,
greg k-h
^ permalink raw reply
* RE: [PATCH] Use firmware provided index to register a network interface
From: Narendra_K @ 2010-09-23 15:51 UTC (permalink / raw)
To: greg
Cc: netdev, linux-hotplug, linux-pci, Matt_Domsch, Charles_Rose,
Jordan_Hargrave, Vijay_Nijhawan
In-Reply-To: <20100923152730.GA1261@kroah.com>
> -----Original Message-----
> From: Greg KH [mailto:greg@kroah.com]
> Sent: Thursday, September 23, 2010 8:58 PM
> To: K, Narendra
> Cc: netdev@vger.kernel.org; linux-hotplug@vger.kernel.org; linux-
> pci@vger.kernel.org; Domsch, Matt; Rose, Charles; Hargrave, Jordan;
> Nijhawan, Vijay
> Subject: Re: [PATCH] Use firmware provided index to register a network
> interface
>
> > >
> > > Ick, again, what's wrong with using udev for this as it is
designed
> > to?
> > > That way no kernel changes are needed, and no one has to rely on
> the
> > > BIOS getting the firmware number right (meaning it will work on
all
> > > types of systems.)
> > >
> >
> > 1. We tried addressing this issue using udev only and without any
> kernel
> > changes, during Nov-Dec 2008 timeframe using Biosdevname udev helper
> > utility. Biosdevname utility has the ability to suggest BIOS
intended
> > name of an interface given its OS name.
> >
> > /sbin/biosdevname -I eth2 - (OS name)
> > eth0 - (Name according to the BIOS)
> >
> > KERNEL!="eth*", GOTO="biosdevname_end"
> > ACTION!="add", GOTO="biosdevname_end"
> > NAME="?*", GOTO="biosdevname_end"
> >
> > PROGRAM="/sbin/biosdevname --policy=all_ethN -i %k",
> > ENV{INTERFACE_NAME}="%c"
> >
> > LABEL="biosdevname_end"
> >
> > We observed that renames in the same namespace, which is ethN
> namespace,
> > resulted in interface names like eth_rename_ren. The solution was
> > susceptible to driver load order. Please refer to this bug report-
> > https://bugzilla.novell.com/show_bug.cgi?idD1079.
> >
> > This solution was not favored.
>
> That's because for some reason you don't want to accept the fact that
> if
> you want to rename things in a persistant manner, you have to do so in
> a
> namespace that is outside of the kernel's normal one.
>
> Now trying to change the kernel namespace itself seems like a bad hack
> around this fact.
>
The patch does not change the existing kernel name space. It adheres to
the existing ethN name space with IFNAMSIZ length requirements. The
patch only makes sure that eth0 always corresponds to what is labeled as
'Gb1' on server chassis, on systems where SMBIOS type 41 record is
available. And removes the need for any renames for the interfaces which
have a firmware index assigned by system firmware, as the very first
name assigned by the kernel will be as expected and deterministic.
With regards,
Narendra K
^ permalink raw reply
* Re: [PATCH] Use firmware provided index to register a network
From: Greg KH @ 2010-09-23 15:27 UTC (permalink / raw)
To: Narendra_K
Cc: netdev, linux-hotplug, linux-pci, Matt_Domsch, Charles_Rose,
Jordan_Hargrave, Vijay_Nijhawan
In-Reply-To: <EDA0A4495861324DA2618B4C45DCB3EE6A0AF8@blrx3m08.blr.amer.dell.com>
On Thu, Sep 23, 2010 at 08:40:44PM +0530, Narendra_K@Dell.com wrote:
> > -----Original Message-----
> > From: Greg KH [mailto:greg@kroah.com]
> > Sent: Thursday, September 23, 2010 12:52 AM
> > To: K, Narendra
> > Cc: netdev@vger.kernel.org; linux-hotplug@vger.kernel.org; linux-
> > pci@vger.kernel.org; Domsch, Matt; Rose, Charles; Hargrave, Jordan;
> > Nijhawan, Vijay
> > Subject: Re: [PATCH] Use firmware provided index to register a network
> > interface
> >
> > On Wed, Sep 22, 2010 at 01:31:38PM -0500, Narendra K wrote:
> > > Hello,
> > >
> > > Here is another approach to address the issue of "eth0 does not
> > always
> > > map to the Integrated NIC Port 1 as denoted on server chassis
> label".
> > > For more details please refer to the thread -
> > > http://marc.info/?l=linux-netdev&m\x128163454631618&w=3.
> > >
> > > Patch makes use of the firmware provided index to derive ethN names.
> > > That way the naming scheme adheres to the existing requirements of
> > > ethN namespace and with IFNAMSIZ length.
> >
> > Ick, again, what's wrong with using udev for this as it is designed
> to?
> > That way no kernel changes are needed, and no one has to rely on the
> > BIOS getting the firmware number right (meaning it will work on all
> > types of systems.)
> >
>
> 1. We tried addressing this issue using udev only and without any kernel
> changes, during Nov-Dec 2008 timeframe using Biosdevname udev helper
> utility. Biosdevname utility has the ability to suggest BIOS intended
> name of an interface given its OS name.
>
> /sbin/biosdevname -I eth2 - (OS name)
> eth0 - (Name according to the BIOS)
>
> KERNEL!="eth*", GOTO="biosdevname_end"
> ACTION!="add", GOTO="biosdevname_end"
> NAME="?*", GOTO="biosdevname_end"
>
> PROGRAM="/sbin/biosdevname --policy=all_ethN -i %k",
> ENV{INTERFACE_NAME}="%c"
>
> LABEL="biosdevname_end"
>
> We observed that renames in the same namespace, which is ethN namespace,
> resulted in interface names like eth_rename_ren. The solution was
> susceptible to driver load order. Please refer to this bug report-
> https://bugzilla.novell.com/show_bug.cgi?idD1079.
>
> This solution was not favored.
That's because for some reason you don't want to accept the fact that if
you want to rename things in a persistant manner, you have to do so in a
namespace that is outside of the kernel's normal one.
Now trying to change the kernel namespace itself seems like a bad hack
around this fact.
thanks,
greg k-h
^ permalink raw reply
* RE: [PATCH] Use firmware provided index to register a network interface
From: Narendra_K @ 2010-09-23 15:25 UTC (permalink / raw)
To: tim, shemminger
Cc: netdev, linux-hotplug, linux-pci, Matt_Domsch, Charles_Rose,
Jordan_Hargrave, Vijay_Nijhawan
In-Reply-To: <4C9AF4EC.7020408@seoss.co.uk>
> -----Original Message-----
> From: Tim Small [mailto:tim@seoss.co.uk]
> Sent: Thursday, September 23, 2010 12:04 PM
> To: Stephen Hemminger
> Cc: K, Narendra; netdev@vger.kernel.org;
linux-hotplug@vger.kernel.org;
> linux-pci@vger.kernel.org; Domsch, Matt; Rose, Charles; Hargrave,
> Jordan; Nijhawan, Vijay
> Subject: Re: [PATCH] Use firmware provided index to register a network
> interface
>
> Stephen Hemminger wrote:
> >>> http://marc.info/?l=linux-netdev&m\x125510301513312&w=2
> >> Out of interest, that link says that doing it in usespace was
> rejected,
> >> but doesn't give any references... I'd be interested to know why
> this
> >> wasn't viable - since this seemed like the best fit at first glance
> -
> >> most people will never use this, so no need to grow their kernel
> size
> >> and complexity?
> >>
> >>
> >
> > This proposal was to ad changes into every application that
> > knows about network names (iproute, iptables, snmp, quagga,
openswan,
> ...)
> > to do aliasing at the application layer.
> >
>
>
> OK, that's bonkers, but what I was referring to was the line in the
> linked post which said "Achieve the above in userspace only using
udev"
> - which I assumed meant to do it once in a udev rename rule by
adapting
> /etc/udev/rules.d/70-persistent-net.rules , /lib/udev/write_net_rules
> etc. - which is what I've used to enforce this sort of convention
> myself
> from time to time.
>
Hi,
I was referring to the solution proposed in this thread -
http://marc.info/?l=linux-netdev&m\x125619338904322&w=3 ([PATCH] udev:
create empty regular files to represent net).
With regards,
Narendra K
^ permalink raw reply
* RE: [PATCH] Use firmware provided index to register a network interface
From: Narendra_K @ 2010-09-23 15:22 UTC (permalink / raw)
To: greg
Cc: netdev, linux-hotplug, linux-pci, Matt_Domsch, Charles_Rose,
Jordan_Hargrave, Vijay_Nijhawan
In-Reply-To: <20100922192228.GB29899@kroah.com>
> -----Original Message-----
> From: Greg KH [mailto:greg@kroah.com]
> Sent: Thursday, September 23, 2010 12:52 AM
> To: K, Narendra
> Cc: netdev@vger.kernel.org; linux-hotplug@vger.kernel.org; linux-
> pci@vger.kernel.org; Domsch, Matt; Rose, Charles; Hargrave, Jordan;
> Nijhawan, Vijay
> Subject: Re: [PATCH] Use firmware provided index to register a network
> interface
>
> On Wed, Sep 22, 2010 at 01:31:38PM -0500, Narendra K wrote:
> > Hello,
> >
> > Here is another approach to address the issue of "eth0 does not
> always
> > map to the Integrated NIC Port 1 as denoted on server chassis
label".
> > For more details please refer to the thread -
> > http://marc.info/?l=linux-netdev&m\x128163454631618&w=3.
> >
> > Patch makes use of the firmware provided index to derive ethN names.
> > That way the naming scheme adheres to the existing requirements of
> > ethN namespace and with IFNAMSIZ length.
>
> Ick, again, what's wrong with using udev for this as it is designed
to?
> That way no kernel changes are needed, and no one has to rely on the
> BIOS getting the firmware number right (meaning it will work on all
> types of systems.)
>
1. We tried addressing this issue using udev only and without any kernel
changes, during Nov-Dec 2008 timeframe using Biosdevname udev helper
utility. Biosdevname utility has the ability to suggest BIOS intended
name of an interface given its OS name.
/sbin/biosdevname -I eth2 - (OS name)
eth0 - (Name according to the BIOS)
KERNEL!="eth*", GOTO="biosdevname_end"
ACTION!="add", GOTO="biosdevname_end"
NAME="?*", GOTO="biosdevname_end"
PROGRAM="/sbin/biosdevname --policy=all_ethN -i %k",
ENV{INTERFACE_NAME}="%c"
LABEL="biosdevname_end"
We observed that renames in the same namespace, which is ethN namespace,
resulted in interface names like eth_rename_ren. The solution was
susceptible to driver load order. Please refer to this bug report-
https://bugzilla.novell.com/show_bug.cgi?idD1079.
This solution was not favored.
2. Based on the suggestions, I am trying to see if we can make use of
the attribute 'index' that is available to udev as a result of the patch
-
http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=commit;h
‘1e1c9b05a8e3559a7aa89083930700a0b9e7ee (PCI: export SMBIOS provided
firmware instance and label to sysfs).(I am not using any udev helper in
this experiment).
On a PowerEdge R805, with 4 BCM5708 Lan-On-Motherboard ports and a dual
port Intel 82576 NIC. In this system the 82576 ports become eth0 and
eth1 and the Lan-On-Motherboard ports are eth2-eth5. Below is how the
70-persistent-net.rules file looks before I modified it -
# PCI device 0x14e4:0x164c (bnx2) (custom name provided by external
tool)
SUBSYSTEM="net", ACTION="add", DRIVERS="?*",
ATTR{address}="00:1e:4f:fc:1b:32", ATTR{type}="1", KERNEL="eth*",
NAME="eth3"
# PCI device 0x14e4:0x164c (bnx2) (custom name provided by external
tool)
SUBSYSTEM="net", ACTION="add", DRIVERS="?*",
ATTR{address}="00:1e:4f:fc:1b:30", ATTR{type}="1", KERNEL="eth*",
NAME="eth2"
# PCI device 0x14e4:0x164c (bnx2) (custom name provided by external
tool)
SUBSYSTEM="net", ACTION="add", DRIVERS="?*",
ATTR{address}="00:1e:4f:fc:00:40", ATTR{type}="1", KERNEL="eth*",
NAME="eth5"
# PCI device 0x8086:0x10c9 (igb) (custom name provided by external tool)
SUBSYSTEM="net", ACTION="add", DRIVERS="?*",
ATTR{address}="00:1b:21:54:33:3c", ATTR{type}="1", KERNEL="eth*",
NAME="eth0"
# PCI device 0x8086:0x10c9 (igb) (custom name provided by external tool)
SUBSYSTEM="net", ACTION="add", DRIVERS="?*",
ATTR{address}="00:1b:21:54:33:3d", ATTR{type}="1", KERNEL="eth*",
NAME="eth1"
# PCI device 0x14e4:0x164c (bnx2) (custom name provided by external
tool)
SUBSYSTEM="net", ACTION="add", DRIVERS="?*",
ATTR{address}="00:1e:4f:fc:00:3e", ATTR{type}="1", KERNEL="eth*",
NAME="eth4"
I modified the rules to use the ATTR{index} as below to get expected
names -
# PCI device 0x14e4:0x164c (bnx2) (custom name provided by external
tool)
SUBSYSTEM="net", ACTION="add", DRIVERS="?*", ATTR{index}="1",
ATTR{type}="1", KERNEL="eth*", NAME="eth0"
# PCI device 0x14e4:0x164c (bnx2) (custom name provided by external
tool)
SUBSYSTEM="net", ACTION="add", DRIVERS="?*", ATTR{index}="2",
ATTR{type}="1", KERNEL="eth*", NAME="eth1"
# PCI device 0x14e4:0x164c (bnx2) (custom name provided by external
tool)
SUBSYSTEM="net", ACTION="add", DRIVERS="?*", ATTR{index}="3",
ATTR{type}="1", KERNEL="eth*", NAME="eth2"
# PCI device 0x8086:0x10c9 (igb) (custom name provided by external tool)
SUBSYSTEM="net", ACTION="add", DRIVERS="?*",
ATTR{address}="00:1b:21:54:33:3c", ATTR{type}="1", KERNEL="eth*",
NAME="eth4"
# PCI device 0x8086:0x10c9 (igb) (custom name provided by external tool)
SUBSYSTEM="net", ACTION="add", DRIVERS="?*",
ATTR{address}="00:1b:21:54:33:3d", ATTR{type}="1", KERNEL="eth*",
NAME="eth5"
# PCI device 0x14e4:0x164c (bnx2) (custom name provided by external
tool)
SUBSYSTEM="net", ACTION="add", DRIVERS="?*", ATTR{index}="4",
ATTR{type}="1", KERNEL="eth*", NAME="eth3"
I observe that the Lan-On-Motherboard ports get named beyond the add-in
interfaces. That is, in the original file the add-in interfaces were
eth4 and eth5. They remain same as expected. But Lan-On-Motherboard
ports get eth6,eth7,eth8,eth9. Dmesg shows the renames that are done
igb 0000:21:00.1: Using MSI-X interrupts. 8 rx queue(s), 8 tx queue(s)
udev: renamed network interface eth1 to eth5
udev: renamed network interface eth0 to eth4
bnx2 0000:0a:00.0: eth3: Broadcom NetXtreme II BCM5708 1000Base-T (B2)
PCI-X 64-bit 133MHz found at mem ec000000, IRQ 19, node addr
00:1e:4f:fc:00:40
udev: renamed network interface eth0 to eth6
udev: renamed network interface eth2 to eth7
udev: renamed network interface eth3 to eth8
udev: renamed network interface eth1 to eth9
I am trying to figure out what might be going on.
With regards,
Narendra K
^ permalink raw reply
* Re: [PATCH] Use firmware provided index to register a network interface
From: Tim Small @ 2010-09-23 6:34 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Narendra K, netdev, linux-hotplug, linux-pci, matt_domsch,
charles_rose, jordan_hargrave, vijay_nijhawan
In-Reply-To: <20100922151645.649d3d7a@nehalam>
Stephen Hemminger wrote:
>>> http://marc.info/?l=linux-netdev&m\x125510301513312&w=2
>> Out of interest, that link says that doing it in usespace was rejected,
>> but doesn't give any references... I'd be interested to know why this
>> wasn't viable - since this seemed like the best fit at first glance -
>> most people will never use this, so no need to grow their kernel size
>> and complexity?
>>
>>
>
> This proposal was to ad changes into every application that
> knows about network names (iproute, iptables, snmp, quagga, openswan, ...)
> to do aliasing at the application layer.
>
OK, that's bonkers, but what I was refering to was the line in the
linked post which said "Achieve the above in userspace only using udev"
- which I assumed meant to do it once in a udev rename rule by adapting
/etc/udev/rules.d/70-persistent-net.rules , /lib/udev/write_net_rules
etc. - which is what I've used to enforce this sort of convention myself
from time to time.
Tim.
--
South East Open Source Solutions Limited
Registered in England and Wales with company number 06134732.
Registered Office: 2 Powell Gardens, Redhill, Surrey, RH1 1TQ
VAT number: 900 6633 53 http://seoss.co.uk/ +44-(0)1273-808309
^ permalink raw reply
* Re: [PATCH] Use firmware provided index to register a network
From: Stephen Hemminger @ 2010-09-22 22:16 UTC (permalink / raw)
To: Tim Small
Cc: Narendra K, netdev, linux-hotplug, linux-pci, matt_domsch,
charles_rose, jordan_hargrave, vijay_nijhawan
In-Reply-To: <4C9A7E39.2020304@buttersideup.com>
On Wed, 22 Sep 2010 23:07:53 +0100
Tim Small <tim@buttersideup.com> wrote:
> Narendra K wrote:
> > Hello,
> >
> > Here is another approach to address the issue of "eth0 does not always
> > map to the Integrated NIC Port 1 as denoted on server chassis label".
> > For more details please refer to the thread -
> > http://marc.info/?l=linux-netdev&m\x128163454631618&w=3.
> >
>
>
> Hi,
>
> Out of interest, that link says that doing it in usespace was rejected,
> but doesn't give any references... I'd be interested to know why this
> wasn't viable - since this seemed like the best fit at first glance -
> most people will never use this, so no need to grow their kernel size
> and complexity?
>
This proposal was to ad changes into every application that
knows about network names (iproute, iptables, snmp, quagga, openswan, ...)
to do aliasing at the application layer.
I rejected it as an unmanageable since it would require changes to so
many packages (many of which are more BSD focused). Also doing aliasing
would lead to security and other issues. For example, if you write a
iptables rule based on the "Embedded NIC 1" rule would it work and know
when the packet name lookup returned eth0, or what about device names
in the Quagga RIB, ...
^ permalink raw reply
* Re: [PATCH] Use firmware provided index to register a network interface
From: Tim Small @ 2010-09-22 22:07 UTC (permalink / raw)
To: Narendra K
Cc: netdev, linux-hotplug, linux-pci, matt_domsch, charles_rose,
jordan_hargrave, vijay_nijhawan
In-Reply-To: <20100922183137.GA7607@auslistsprd01.us.dell.com>
Narendra K wrote:
> Hello,
>
> Here is another approach to address the issue of "eth0 does not always
> map to the Integrated NIC Port 1 as denoted on server chassis label".
> For more details please refer to the thread -
> http://marc.info/?l=linux-netdev&m\x128163454631618&w=3.
>
Hi,
Out of interest, that link says that doing it in usespace was rejected,
but doesn't give any references... I'd be interested to know why this
wasn't viable - since this seemed like the best fit at first glance -
most people will never use this, so no need to grow their kernel size
and complexity?
Cheers,
Tim.
^ permalink raw reply
* Re: [PATCH] Use firmware provided index to register a network
From: Greg KH @ 2010-09-22 19:22 UTC (permalink / raw)
To: Narendra K
Cc: netdev, linux-hotplug, linux-pci, matt_domsch, charles_rose,
jordan_hargrave, vijay_nijhawan
In-Reply-To: <20100922183137.GA7607@auslistsprd01.us.dell.com>
On Wed, Sep 22, 2010 at 01:31:38PM -0500, Narendra K wrote:
> Hello,
>
> Here is another approach to address the issue of "eth0 does not always
> map to the Integrated NIC Port 1 as denoted on server chassis label".
> For more details please refer to the thread -
> http://marc.info/?l=linux-netdev&m\x128163454631618&w=3.
>
> Patch makes use of the firmware provided index to derive ethN names.
> That way the naming scheme adheres to the existing requirements of
> ethN namespace and with IFNAMSIZ length.
Ick, again, what's wrong with using udev for this as it is designed to?
That way no kernel changes are needed, and no one has to rely on the
BIOS getting the firmware number right (meaning it will work on all
types of systems.)
thanks,
greg k-h
^ permalink raw reply
* [PATCH] Use firmware provided index to register a network interface
From: Narendra K @ 2010-09-22 18:31 UTC (permalink / raw)
To: netdev, linux-hotplug, linux-pci
Cc: matt_domsch, charles_rose, jordan_hargrave, vijay_nijhawan
Hello,
Here is another approach to address the issue of "eth0 does not always
map to the Integrated NIC Port 1 as denoted on server chassis label".
For more details please refer to the thread -
http://marc.info/?l=linux-netdev&m\x128163454631618&w=3.
Patch makes use of the firmware provided index to derive ethN names.
That way the naming scheme adheres to the existing requirements of
ethN namespace and with IFNAMSIZ length.
Please find the patch here -
From: Narendra K <narendra_k@dell.com>
Subject: [PATCH] Use firmware provided index to register a network device
This patch uses the firmware provided index to derive the ethN name.
If the firmware provides an index for the corresponding pdev, the N
is derived from the index.
As an example, consider a PowerEdge R710 which has 4 BCM5709
Lan-On-Motherboard ports,1 Intel 82572EI port and 4 82575GB ports.
The system firmware communicates the order of the 4 Lan-On-Motherboard
ports by assigning indexes to each one of them. This is available to
the OS as the SMBIOS type 41 record(for onboard devices), in the field
'device type index'. It looks like below -
Handle 0x2900, DMI type 41, 11 bytes
Onboard Device
Reference Designation: Embedded NIC 1
Type: Ethernet
Status: Enabled
Type Instance: 1
Bus Address: 0000:01:00.0
Handle 0x2901, DMI type 41, 11 bytes
Onboard Device
Reference Designation: Embedded NIC 2
Type: Ethernet
Status: Enabled
Type Instance: 2
Bus Address: 0000:01:00.1
Handle 0x2902, DMI type 41, 11 bytes
Onboard Device
Reference Designation: Embedded NIC 3
Type: Ethernet
Status: Enabled
Type Instance: 3
Bus Address: 0000:02:00.0
Handle 0x2903, DMI type 41, 11 bytes
Onboard Device
Reference Designation: Embedded NIC 4
Type: Ethernet
Status: Enabled
Type Instance: 4
Bus Address: 0000:02:00.1
The OS can use this index to name the network interfaces as below.
Onboard devices -
Interface Fwindex Driver
Name
eth[fwindex - 1] =eth0 1 bnx2
eth[fwindex - 1] =eth1 2 bnx2
eth[fwindex - 1] =eth2 3 bnx2
eth[fwindex - 1] =eth3 4 bnx2
The add-in devices do not get any index and they will get names from
eth4 onwards.
Add-in interfaces -
eth4 e1000e
eth5 igb
eth6 igb
eth7 igb
eth8 igb
With this patch,
1. This patch adheres to the established ABI of ethN namespace with
IFNAMSIZ length and ensures that onboard network interfaces get
expected names at the first instance itself and avoids any renaming
later.
2. The 'eth0' of the OS always corresponds to the 'Gb1' as labeled on
the system chassis. There is determinism in the way Lan-On-Motherboard
ports get named.
3. The add-in devices will always be named from beyond what the
Lan-On-Motherboard names as show above. But there is no determinism
as to which add-in interface gets what ethN name.
Signed-off-by: Narendra K <narendra_k@dell.com>
---
drivers/pci/pci-label.c | 1 +
drivers/pci/pci-sysfs.c | 5 +++++
include/linux/netdevice.h | 2 ++
include/linux/pci.h | 1 +
net/core/dev.c | 28 ++++++++++++++++++++++------
5 files changed, 31 insertions(+), 6 deletions(-)
diff --git a/drivers/pci/pci-label.c b/drivers/pci/pci-label.c
index 90c0a72..8086268 100644
--- a/drivers/pci/pci-label.c
+++ b/drivers/pci/pci-label.c
@@ -55,6 +55,7 @@ find_smbios_instance_string(struct pci_dev *pdev, char *buf,
"%s\n",
dmi->name);
}
+ pdev->firmware_index = donboard->instance;
return strlen(dmi->name);
}
}
diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
index b5a7d9b..448ed9d 100644
--- a/drivers/pci/pci-sysfs.c
+++ b/drivers/pci/pci-sysfs.c
@@ -28,6 +28,7 @@
#include "pci.h"
static int sysfs_initialized; /* = 0 */
+int pci_netdevs_with_fwindex;
/* show configuration fields */
#define pci_config_attr(field, format_string) \
@@ -1167,6 +1168,10 @@ int __must_check pci_create_sysfs_dev_files (struct pci_dev *pdev)
pci_create_firmware_label_files(pdev);
+ if (pdev->firmware_index && (pdev->class >> 16) =
+ PCI_BASE_CLASS_NETWORK)
+ pci_netdevs_with_fwindex++;
+
return 0;
err_vga_file:
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 46c36ff..4398dcf 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -1080,6 +1080,8 @@ struct net_device {
#define NETDEV_ALIGN 32
+extern int pci_netdevs_with_fwindex;
+
static inline
struct netdev_queue *netdev_get_tx_queue(const struct net_device *dev,
unsigned int index)
diff --git a/include/linux/pci.h b/include/linux/pci.h
index b1d1795..90113bb 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -243,6 +243,7 @@ struct pci_dev {
unsigned short subsystem_vendor;
unsigned short subsystem_device;
unsigned int class; /* 3 bytes: (base,sub,prog-if) */
+ unsigned int firmware_index; /* Firmware provided index */
u8 revision; /* PCI revision, low byte of class word */
u8 hdr_type; /* PCI header type (`multi' flag masked out) */
u8 pcie_cap; /* PCI-E capability offset */
diff --git a/net/core/dev.c b/net/core/dev.c
index 1ae6543..b177ccc 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -855,7 +855,7 @@ EXPORT_SYMBOL(dev_valid_name);
/**
* __dev_alloc_name - allocate a name for a device
- * @net: network namespace to allocate the device name in
+ * @dev: device
* @name: name format string
* @buf: scratch buffer and result name string
*
@@ -868,13 +868,15 @@ EXPORT_SYMBOL(dev_valid_name);
* Returns the number of the unit assigned or a negative errno code.
*/
-static int __dev_alloc_name(struct net *net, const char *name, char *buf)
+static int __dev_alloc_name(struct net_device *dev, const char *name, char *buf)
{
int i = 0;
const char *p;
const int max_netdevices = 8*PAGE_SIZE;
unsigned long *inuse;
struct net_device *d;
+ struct net *net;
+ struct pci_dev *pdev;
p = strnchr(name, IFNAMSIZ-1, '%');
if (p) {
@@ -886,15 +888,31 @@ static int __dev_alloc_name(struct net *net, const char *name, char *buf)
if (p[1] != 'd' || strchr(p + 2, '%'))
return -EINVAL;
+ pdev = to_pci_dev(dev->dev.parent);
+ if (pdev && pdev->firmware_index) {
+ snprintf(buf, IFNAMSIZ, name,
+ pdev->firmware_index - 1);
+ return pdev->firmware_index - 1;
+ }
+
/* Use one page as a bit array of possible slots */
inuse = (unsigned long *) get_zeroed_page(GFP_ATOMIC);
if (!inuse)
return -ENOMEM;
+ /* Reserve 0 to < pci_netdevs_with_fwindex for integrated
+ * ports with fwindex and allocate from pci_netdevs_with_fwindex
+ * onwards for add-in devices
+ */
+ for (i = 0; i < pci_netdevs_with_fwindex; i++)
+ set_bit(i, inuse);
+
+ net = dev_net(dev);
+
for_each_netdev(net, d) {
if (!sscanf(d->name, name, &i))
continue;
- if (i < 0 || i >= max_netdevices)
+ if (i < pci_netdevs_with_fwindex || i >= max_netdevices)
continue;
/* avoid cases where sscanf is not exact inverse of printf */
@@ -936,12 +954,10 @@ static int __dev_alloc_name(struct net *net, const char *name, char *buf)
int dev_alloc_name(struct net_device *dev, const char *name)
{
char buf[IFNAMSIZ];
- struct net *net;
int ret;
BUG_ON(!dev_net(dev));
- net = dev_net(dev);
- ret = __dev_alloc_name(net, name, buf);
+ ret = __dev_alloc_name(dev, name, buf);
if (ret >= 0)
strlcpy(dev->name, buf, IFNAMSIZ);
return ret;
--
1.7.0.1
With regards,
Narendra K
^ permalink raw reply related
* help with removing symlinks
From: Jeremy Mordkoff @ 2010-09-21 15:16 UTC (permalink / raw)
To: linux-hotplug
I need a symlink removed as quickly as possible after the device is
disconnected.
Here is my rule:
# ZeeVee
ACTION="remove", RUN+=/etc/zv_clean
SUBSYSTEM!="tty", GOTO="zeevee_end"
KERNEL="ttyUSB[0-9]*|ttyACM[0-9]*",
SYMLINK+="ZvBox/$ENV{ID_SERIAL_SHORT}", MODE="0666"
LABEL="zeevee_end"
I thought symlinks get deleted by default, but no luck. So I tried the
ACTION statement and a script to find the orphan links, but my script
does not fire.
^ permalink raw reply
* Re: ID_FS_LABEL and udev versions
From: Kay Sievers @ 2010-09-20 12:31 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <AANLkTikRM8CEZuT+xrJJsr25XCJLb6fGEdWvfx9k_Rwt@mail.gmail.com>
On Mon, Sep 20, 2010 at 13:44, Nathan Stewart <swarfrat@gmail.com> wrote:
> Can I use ID_FS_LABEL in my rules or must it be relegated to the script?
Your rules file name must be sorted after the rules file that imports
the ID_FS* properties. Is that the case?
Kay
^ permalink raw reply
* ID_FS_LABEL and udev versions
From: Nathan Stewart @ 2010-09-20 11:44 UTC (permalink / raw)
To: linux-hotplug
I'm trying to write a set of udev rules for managing rotated backup
drives. The real system this is going on is Red Hat 5.3. The scratch
machine I've been working on is Ubuntu 10.04. (There's a ton of
documentation out there that's old that doesn't really work with
either machine.)
Since I'm actually trying to manage two drives which could possibly be
mounted at the same time, I'm using a script rather than trying to do
everything in the rule. So far, at least on ubuntu, this works:
ACTION="add", KERNEL="sd[a-z][0-9]", SUBSYSTEM="block",
RUN+="/usr/local/bin/usb_block_added %k"
ACTION="remove", KERNEL="sd[a-z][0-9]", SUBSYSTEM="block",
RUN+="/usr/local/bin/usb_block_removed %k"
But:
ACTION="add", KERNEL="sd[a-z][0-9]", SUBSYSTEM="block",
ENV{ID_FS_LABEL}="backup", RUN+="/usr/local/bin/usb_block_added %k"
does not. udevadm test /block/sdd3 appears to show the rules file is
being processed as expected. If I remove ENV{ID_FS_LABEL} and test for
that environment variable in the script, it is present and contains
the expected value.There are log messages in /var/log/daemon about
SYSFS{} will be removed, but they come from Ubuntu rules
(45-hpdjconsole), not this rule.
Can I use ID_FS_LABEL in my rules or must it be relegated to the script?
^ permalink raw reply
* Re: gudev: a few missing annotations
From: Kay Sievers @ 2010-09-20 8:26 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <4C95061E.1080602@gmx.de>
On Sat, Sep 18, 2010 at 20:34, Torsten Schoenfeld <kaffeetisch@gmx.de> wrote:
> Here are a few missing gudev annotations that newer gobject-introspection
> versions demand.
Applied.
Thanks,
Kay
^ permalink raw reply
* gudev: a few missing annotations
From: Torsten Schoenfeld @ 2010-09-18 18:34 UTC (permalink / raw)
To: linux-hotplug
[-- Attachment #1: Type: text/plain, Size: 132 bytes --]
Here are a few missing gudev annotations that newer
gobject-introspection versions demand.
[I'm not subscribed, so please CC me.]
[-- Attachment #2: gudev-annotations.patch --]
[-- Type: text/x-patch, Size: 3379 bytes --]
diff --git a/extras/gudev/gudevclient.c b/extras/gudev/gudevclient.c
index e829ca3..9ebd8f8 100644
--- a/extras/gudev/gudevclient.c
+++ b/extras/gudev/gudevclient.c
@@ -316,7 +316,7 @@ g_udev_client_init (GUdevClient *client)
/**
* g_udev_client_new:
- * @subsystems: (allow-none): A %NULL terminated string array of subsystems to listen for uevents on, %NULL to not listen on uevents at all, or an empty array to listen to uevents on all subsystems. See the documentation for the #GUdevClient:subsystems property for details on this parameter.
+ * @subsystems: (array zero-terminated=1) (element-type utf8) (transfer none) (allow-none): A %NULL terminated string array of subsystems to listen for uevents on, %NULL to not listen on uevents at all, or an empty array to listen to uevents on all subsystems. See the documentation for the #GUdevClient:subsystems property for details on this parameter.
*
* Constructs a #GUdevClient object that can be used to query
* information about devices. Connect to the #GUdevClient::uevent
@@ -339,7 +339,7 @@ g_udev_client_new (const gchar * const *subsystems)
*
* Gets all devices belonging to @subsystem.
*
- * Returns: (element-type GUdevDevice): A list of #GUdevDevice objects. The caller should free the result by using g_object_unref() on each element in the list and then g_list_free() on the list.
+ * Returns: (element-type GUdevDevice) (transfer full): A list of #GUdevDevice objects. The caller should free the result by using g_object_unref() on each element in the list and then g_list_free() on the list.
*/
GList *
g_udev_client_query_by_subsystem (GUdevClient *client,
@@ -392,7 +392,7 @@ g_udev_client_query_by_subsystem (GUdevClient *client,
*
* Looks up a device for a type and device number.
*
- * Returns: A #GUdevDevice object or %NULL if the device was not found. Free with g_object_unref().
+ * Returns: (transfer full): A #GUdevDevice object or %NULL if the device was not found. Free with g_object_unref().
*/
GUdevDevice *
g_udev_client_query_by_device_number (GUdevClient *client,
@@ -424,7 +424,7 @@ g_udev_client_query_by_device_number (GUdevClient *client,
*
* Looks up a device for a device file.
*
- * Returns: A #GUdevDevice object or %NULL if the device was not found. Free with g_object_unref().
+ * Returns: (transfer full): A #GUdevDevice object or %NULL if the device was not found. Free with g_object_unref().
*/
GUdevDevice *
g_udev_client_query_by_device_file (GUdevClient *client,
@@ -460,7 +460,7 @@ g_udev_client_query_by_device_file (GUdevClient *client,
*
* Looks up a device for a sysfs path.
*
- * Returns: A #GUdevDevice object or %NULL if the device was not found. Free with g_object_unref().
+ * Returns: (transfer full): A #GUdevDevice object or %NULL if the device was not found. Free with g_object_unref().
*/
GUdevDevice *
g_udev_client_query_by_sysfs_path (GUdevClient *client,
@@ -492,7 +492,7 @@ g_udev_client_query_by_sysfs_path (GUdevClient *client,
*
* Looks up a device for a subsystem and name.
*
- * Returns: A #GUdevDevice object or %NULL if the device was not found. Free with g_object_unref().
+ * Returns: (transfer full): A #GUdevDevice object or %NULL if the device was not found. Free with g_object_unref().
*/
GUdevDevice *
g_udev_client_query_by_subsystem_and_name (GUdevClient *client,
^ permalink raw reply related
* Re: Patch to file 95-keyboard-force-release.rules
From: Martin Pitt @ 2010-09-14 16:29 UTC (permalink / raw)
To: linux-hotplug
[-- Attachment #1: Type: text/plain, Size: 738 bytes --]
Hello Ednilton,
Ednilton Santos de Oliveira [Thu, Sep 2, 2010 at 23:02]:
> It follows attached the patch to fix the volume hotkey problem that
> we have with a Brazilian notebook from CCE vendor and
> model ILE332.
>
> The original vendor is OEM and product I42IL1.
Unfortunately neither of those is very specific to a particular
notebook vendor/product. If nothing else helps, we can commit that,
but before that, can I ask you to give us the output of
grep . /sys/class/dmi/id/*
? Perhaps there are some other fields there which are a bit less
sloppy.
Thanks,
Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: Use GROUP= in a rule matching an interface of the device?
From: Ludovic Rousseau @ 2010-09-13 12:56 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <AANLkTim1MpL_uvuNhyEZ=aU+y0g9tQkG94pxj4XFa9xP@mail.gmail.com>
2010/9/13 Marco d'Itri <md@linux.it>:
> On Sep 13, Ludovic Rousseau <ludovic.rousseau@gmail.com> wrote:
>
>> My 50-udev-default-rules files does not use usb_id (file attached).
>> But other files in /lib/udev/rules.d/ do. The first one is
>> 60-persistent-alsa.rules
> Debian applies the permissions at 91, so your file needs to sort after
> 91-permissions.rules. This is documented in README.Debian.
Renamed the rule file to 92_pcscd_ccid.rules.
And it works! :-)
Thanks to all,
--
Dr. Ludovic Rousseau
^ permalink raw reply
* Re: Use GROUP= in a rule matching an interface of the device?
From: Marco d'Itri @ 2010-09-13 12:48 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <AANLkTim1MpL_uvuNhyEZ=aU+y0g9tQkG94pxj4XFa9xP@mail.gmail.com>
On Sep 13, Ludovic Rousseau <ludovic.rousseau@gmail.com> wrote:
> My 50-udev-default-rules files does not use usb_id (file attached).
> But other files in /lib/udev/rules.d/ do. The first one is
> 60-persistent-alsa.rules
Debian applies the permissions at 91, so your file needs to sort after
91-permissions.rules. This is documented in README.Debian.
Kay, if rules files can depend of usb_id being ran at a certain point
instead of running it themselves like the standard rules files currently
do then you should say so...
--
ciao,
Marco
^ permalink raw reply
* Re: Use GROUP= in a rule matching an interface of the device?
From: Ludovic Rousseau @ 2010-09-13 12:42 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <AANLkTim1MpL_uvuNhyEZ=aU+y0g9tQkG94pxj4XFa9xP@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1747 bytes --]
2010/9/13 Kay Sievers <kay.sievers@vrfy.org>:
> On Fri, Sep 10, 2010 at 17:14, Ludovic Rousseau
> <ludovic.rousseau@gmail.com> wrote:
>> 2010/9/9 Kay Sievers <kay.sievers@vrfy.org>:
>
>>> Udev parses the usb descriptors and makes them available in a
>>> property. That's the only way to access usb_interface properties from
>>> the usb_device event.
>>>
>>> Something like:
>>> SUBSYSTEM=="usb", ENV{ID_USB_INTERFACES}="*:0b0000:*", GROUP= ...
>>> should do it.
>>
>> It works but is not what I need.
>> - Why do you use = instead of == for ENV{ID_USB_INTERFACES}? I want to
>> check the value of ID_USB_INTERFACES, not set it.
>> - Why use "*" in "*:0b0000:*"?
>>
>> Instead I used a ==
>> SUBSYSTEM=="usb", ENV{ID_USB_INTERFACES}=="*:0b0000:*", GROUP="pcscd"
>> or
>> SUBSYSTEM=="usb", ENV{ID_USB_INTERFACES}==":0b0000:", GROUP="pcscd"
>> But it does not work :-(
>
> Sure, it should be ==. Make sure that your rule file sorts after
> 50-udev-default-rules, which calls usb_id, and sets this property.
My 50-udev-default-rules files does not use usb_id (file attached).
But other files in /lib/udev/rules.d/ do. The first one is
60-persistent-alsa.rules
I renamed my rule file from 50_pcscd_ccid.rules to 51_pcscd_ccid.rules
to be sorted after 50-udev-default-rules but the rule still do not
work.
I can see the "ID_USB_INTERFACES=:0b0000:" line in "udevadm monitor
--env --kernel udev" output but that is for an interface, not for the
device itself.
Maybe that is because my 50-udev-default-rules file is not using usb_id?
What is the use of GROUP="" supposed to do on an interface?
Is it possible to propagate the group change on the parent device node?
Thanks
--
Dr. Ludovic Rousseau
[-- Attachment #2: 50-udev-default.rules --]
[-- Type: application/octet-stream, Size: 3548 bytes --]
SUBSYSTEM=="block", SYMLINK{unique}+="block/%M:%m"
SUBSYSTEM!="block", SYMLINK{unique}+="char/%M:%m"
# import the properties of optical drives
ACTION!="remove", SUBSYSTEM=="block", ENV{DEVTYPE}=="disk", \
KERNEL=="sr[0-9]*|hd[a-z]|pcd[0-9]|xvd*", \
IMPORT{program}="cdrom_id --export $tempnode"
# SCSI devices
SUBSYSTEMS=="scsi", KERNEL=="sr[0-9]*", SYMLINK+="scd%n"
SUBSYSTEM=="bsg", NAME="bsg/%k"
# workaround for kernels < 2.6.30
SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", WAIT_FOR_SYSFS="descriptors"
# USB devices
SUBSYSTEMS=="usb", KERNEL=="auer[0-9]*", NAME="usb/%k"
SUBSYSTEMS=="usb", KERNEL=="cpad[0-9]*", NAME="usb/%k"
SUBSYSTEMS=="usb", KERNEL=="dabusb[0-9]*", NAME="usb/%k"
SUBSYSTEMS=="usb", KERNEL=="hiddev[0-9]*", NAME="usb/%k"
SUBSYSTEMS=="usb", KERNEL=="legousbtower[0-9]*", NAME="usb/%k"
SUBSYSTEMS=="usb", KERNEL=="lp[0-9]*", NAME="usb/%k"
SUBSYSTEMS=="usb", KERNEL=="iowarrior[0-9]*", NAME="usb/%k"
SUBSYSTEMS=="usb", KERNEL=="ttyUSB*", \
ATTRS{product}=="[Hh]andspring*Treo*|[Hh]andspring*Visor*|[Pp]alm*Handheld*", \
SYMLINK+="pilot"
# usbfs-like devices
SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", NAME="bus/usb/$env{BUSNUM}/$env{DEVNUM}"
# serial devices
KERNEL=="capi", NAME="capi20",
KERNEL=="capi[0-9]*", NAME="capi/%n"
# video devices
KERNEL=="dvb*", ENV{DVB_ADAPTER_NUM}=="?*", NAME="dvb/adapter$env{DVB_ADAPTER_NUM}/$env{DVB_DEVICE_TYPE}$env{DVB_DEVICE_NUM}"
# workaround for kernels < 2.6.29
KERNEL=="dvb*", ENV{DVB_ADAPTER_NUM}=="", PROGRAM="/bin/sh -c 'K=%k; K=$${K#dvb}; printf dvb/adapter%%i/%%s $${K%%%%.*} $${K#*.}", ACTION!="remove", \
NAME="$result"
KERNEL=="card[0-9]*", NAME="dri/%k"
# virtio serial / console ports
KERNEL=="vport*", ATTR{name}=="?*", SYMLINK+="virtio-ports/$attr{name}"
# misc devices
KERNEL=="hw_random", NAME="hwrng"
KERNEL=="tun", NAME="net/%k"
KERNEL=="evtchn", NAME="xen/%k"
SUBSYSTEM=="rtc", DRIVERS=="rtc_cmos", SYMLINK+="rtc"
KERNEL=="rawctl", NAME="raw/rawctl"
KERNEL=="cdemu[0-9]*", NAME="cdemu/%n"
KERNEL=="pktcdvd[0-9]*", NAME="pktcdvd/%n"
KERNEL=="pktcdvd", NAME="pktcdvd/control"
KERNEL=="cpu[0-9]*", NAME="cpu/%n/cpuid"
KERNEL=="msr[0-9]*", NAME="cpu/%n/msr"
KERNEL=="microcode", NAME="cpu/microcode"
KERNEL=="umad*", NAME="infiniband/%k"
KERNEL=="issm*", NAME="infiniband/%k"
KERNEL=="uverbs*", NAME="infiniband/%k"
KERNEL=="ucm*", NAME="infiniband/%k"
KERNEL=="uat", NAME="infiniband/%k"
KERNEL=="ucma", NAME="infiniband/%k"
KERNEL=="rdma_cm", NAME="infiniband/%k"
# ALSA devices
KERNEL=="controlC[0-9]*", NAME="snd/%k"
KERNEL=="hwC[D0-9]*", NAME="snd/%k"
KERNEL=="pcmC[D0-9cp]*", NAME="snd/%k"
KERNEL=="midiC[D0-9]*", NAME="snd/%k"
KERNEL=="timer", NAME="snd/%k"
KERNEL=="seq", NAME="snd/%k"
KERNEL=="snd", SUBSYSTEM=="module", ACTION=="add", \
RUN+="/bin/ln -sf /proc/asound/oss/sndstat $root/sndstat"
# ieee1394 devices
KERNEL=="dv1394*", NAME="dv1394/%n"
KERNEL=="video1394*", NAME="video1394/%n"
# input devices
KERNEL=="mice", NAME="input/%k"
KERNEL=="mouse[0-9]*", NAME="input/%k"
KERNEL=="event[0-9]*", NAME="input/%k"
KERNEL=="js[0-9]*", NAME="input/%k"
KERNEL=="ts[0-9]*", NAME="input/%k"
KERNEL=="uinput", NAME="input/%k"
# Zaptel
KERNEL=="zapctl", NAME="zap/ctl"
KERNEL=="zapchannel", NAME="zap/channel"
KERNEL=="zappseudo", NAME="zap/pseudo"
KERNEL=="zaptimer", NAME="zap/timer"
KERNEL=="transcode", NAME="zap/transcode"
KERNEL=="zap[0-9]*", NAME="zap/%n"
# AOE character devices
SUBSYSTEM=="aoe", NAME="etherd/%k"
KERNEL=="device-mapper", NAME="mapper/control"
^ permalink raw reply
* Re: Use GROUP= in a rule matching an interface of the device?
From: Kay Sievers @ 2010-09-13 9:34 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <AANLkTim1MpL_uvuNhyEZ=aU+y0g9tQkG94pxj4XFa9xP@mail.gmail.com>
On Fri, Sep 10, 2010 at 17:14, Ludovic Rousseau
<ludovic.rousseau@gmail.com> wrote:
> 2010/9/9 Kay Sievers <kay.sievers@vrfy.org>:
>> Udev parses the usb descriptors and makes them available in a
>> property. That's the only way to access usb_interface properties from
>> the usb_device event.
>>
>> Something like:
>> Â SUBSYSTEM="usb", ENV{ID_USB_INTERFACES}="*:0b0000:*", GROUP= ...
>> should do it.
>
> It works but is not what I need.
> - Why do you use = instead of = for ENV{ID_USB_INTERFACES}? I want to
> check the value of ID_USB_INTERFACES, not set it.
> - Why use "*" in "*:0b0000:*"?
>
> Instead I used a =
> SUBSYSTEM="usb", ENV{ID_USB_INTERFACES}="*:0b0000:*", GROUP="pcscd"
> or
> SUBSYSTEM="usb", ENV{ID_USB_INTERFACES}=":0b0000:", GROUP="pcscd"
> But it does not work :-(
Sure, it should be =. Make sure that your rule file sorts after
50-udev-default-rules, which calls usb_id, and sets this property.
Kay
^ permalink raw reply
* Re: [PATCH] rules: add udev rule for ath9k_htc (AR7010) device
From: Rajkumar Manoharan @ 2010-09-13 6:44 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1284116300-9060-1-git-send-email-rmanoharan@atheros.com>
On Fri, Sep 10, 2010 at 04:50:01PM +0530, Kay Sievers wrote:
> On Fri, Sep 10, 2010 at 12:58, Rajkumar Manoharan
> <rmanoharan@atheros.com> wrote:
> > AR7010 cards detected as USB Mass storage mode by default and an eject
> > command is required to switch to wireless mode.
>
> This has nothing to do with persistent device naming, and the core of
> udev can not be made device specific. It's installed on all
> architectures and systems, and therefore such hardware specific
> matches can not be in the default rule set.
>
> Udev rules must not call any tools from /usr. Some packages do that,
> but the main udev package should not do that. Note, that I absolutely
> don't mind if people do that, because I think /usr must _never_ be on
> a separate partition.
>
> Also the main udev package can not ship hardware specific rules,
> nobody will care about them, and they will no be maintained here and
> just bit-rot. Maybe it can go into the usb_modeswitch package, which
> does this eject thing for many other devices?
>
> Thanks,
> Kay
Thanks for your input and the rule has been integrated into usb_modeswitch
package.
Thanks,
Rajkumar
^ permalink raw reply
* Re: Use GROUP= in a rule matching an interface of the device?
From: Ludovic Rousseau @ 2010-09-10 15:14 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <AANLkTim1MpL_uvuNhyEZ=aU+y0g9tQkG94pxj4XFa9xP@mail.gmail.com>
2010/9/9 Kay Sievers <kay.sievers@vrfy.org>:
> On Thu, Sep 9, 2010 at 11:21, Ludovic Rousseau
> <ludovic.rousseau@gmail.com> wrote:
>> I am trying to write a udev configuration file to change the group
>> ownership of the device if the device contains a CCID interface
>> (bInterfaceClass = 11 or 0x0B).
>>
>> I would like to use something like:
>> ATTR{bInterfaceClass}="0b", GROUP="pcscd"
>> but that does not work.
>
> That not possible. Udev can only match on properties of the device
> ATTR or a parent device ATTRS.
>
> The device node you want to set the group to is the usb_device, but
> the match you want to do is on the usb_interface. At the moment the
> usb_device event is handled, the usb_interface does not exist, so this
> can never match. And from the usb_interface, which is a children and
> comes after the usb_device, you can not change the parent device node.
>
> Udev parses the usb descriptors and makes them available in a
> property. That's the only way to access usb_interface properties from
> the usb_device event.
>
> Something like:
> SUBSYSTEM="usb", ENV{ID_USB_INTERFACES}="*:0b0000:*", GROUP= ...
> should do it.
It works but is not what I need.
- Why do you use = instead of = for ENV{ID_USB_INTERFACES}? I want to
check the value of ID_USB_INTERFACES, not set it.
- Why use "*" in "*:0b0000:*"?
Instead I used a =
SUBSYSTEM="usb", ENV{ID_USB_INTERFACES}="*:0b0000:*", GROUP="pcscd"
or
SUBSYSTEM="usb", ENV{ID_USB_INTERFACES}=":0b0000:", GROUP="pcscd"
But it does not work :-(
So I still have no working solution (except using RUN+=)
Thanks
--
Dr. Ludovic Rousseau
^ permalink raw reply
* Re: Use GROUP= in a rule matching an interface of the device?
From: Kay Sievers @ 2010-09-10 11:24 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <AANLkTim1MpL_uvuNhyEZ=aU+y0g9tQkG94pxj4XFa9xP@mail.gmail.com>
On Fri, Sep 10, 2010 at 11:49, Ludovic Rousseau
<ludovic.rousseau@gmail.com> wrote:
> 2010/9/9 David Zeuthen <zeuthen@gmail.com>:
>> On Thu, Sep 9, 2010 at 5:57 AM, Ludovic Rousseau
>> <ludovic.rousseau@gmail.com> wrote:
>>> > Something like:
>>> > Â SUBSYSTEM="usb", ENV{ID_USB_INTERFACES}="*:0b0000:*", GROUP= ...
>>> > should do it.
>>>
>>> Yes, it does work.
>>>
>>> But I find the rule more obscure.
>>>
>>> Since performance is not a critical point for me I think I will stay with:
>>> ATTRS{bInterfaceClass}="0b", RUN+="/bin/chgrp pcscd $root/$parent"
>>
>> Please don't. It's racy. In particular it will break if you have
>> daemons or apps listening for uevents and doing stuff when the device
>> node appears.
>
> Would the race issue disappear if I use RUN= instead of RUN+=?
No it wouldn't. It will break all other earlier rules. Device event
must never operate on other devices like their parent in this case.
It's just totally wrong to do anything like that. The next event for
the parent will restore the original mode again, without ever calling
your chgrp hack.
> The chgrp command should not take to long to execute.
It's not a matter of 'long'. A race is a race, and must be avoided.
Kay
^ permalink raw reply
* Re: [PATCH] rules: add udev rule for ath9k_htc (AR7010) device
From: Kay Sievers @ 2010-09-10 11:20 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1284116300-9060-1-git-send-email-rmanoharan@atheros.com>
On Fri, Sep 10, 2010 at 12:58, Rajkumar Manoharan
<rmanoharan@atheros.com> wrote:
> AR7010 cards detected as USB Mass storage mode by default and an eject
> command is required to switch to wireless mode.
This has nothing to do with persistent device naming, and the core of
udev can not be made device specific. It's installed on all
architectures and systems, and therefore such hardware specific
matches can not be in the default rule set.
Udev rules must not call any tools from /usr. Some packages do that,
but the main udev package should not do that. Note, that I absolutely
don't mind if people do that, because I think /usr must _never_ be on
a separate partition.
Also the main udev package can not ship hardware specific rules,
nobody will care about them, and they will no be maintained here and
just bit-rot. Maybe it can go into the usb_modeswitch package, which
does this eject thing for many other devices?
Thanks,
Kay
^ permalink raw reply
* Re: Use GROUP= in a rule matching an interface of the device?
From: Marco d'Itri @ 2010-09-10 11:13 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <AANLkTim1MpL_uvuNhyEZ=aU+y0g9tQkG94pxj4XFa9xP@mail.gmail.com>
On Sep 10, Ludovic Rousseau <ludovic.rousseau@gmail.com> wrote:
> Would the race issue disappear if I use RUN= instead of RUN+=?
No. Please use GROUP, it works and is actually easier to understand what
it does.
--
ciao,
Marco
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox