* 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
* [PATCH] Add new DMI_VENDOR for MSI notebook in 95-keymap.rules
From: Lee, Chun-Yi @ 2010-09-25 8:50 UTC (permalink / raw)
To: linux-hotplug
Add new DMI_VENDOR "Micro-Star International" in 95-keymap.rules,
for enable the hotkey mapping.
Signed-off-by: Lee, Chun-Yi <jlee@novell.com>
---
| 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
--git a/extras/keymap/95-keymap.rules b/extras/keymap/95-keymap.rules
index 9bc3cb6..eda006e 100644
--- a/extras/keymap/95-keymap.rules
+++ b/extras/keymap/95-keymap.rules
@@ -109,6 +109,7 @@ ENV{DMI_VENDOR}="MEDION*", ATTR{[dmi/id]product_name}="*FID2060*", RUN+="keyma
ENV{DMI_VENDOR}="MEDIONNB", ATTR{[dmi/id]product_name}="A555*", RUN+="keymap $name medionnb-a555"
ENV{DMI_VENDOR}="MICRO-STAR*", RUN+="keymap $name micro-star"
+ENV{DMI_VENDOR}="Micro-Star International", RUN+="keymap $name micro-star"
# some MSI models generate ACPI/input events on the LNXVIDEO input devices,
# plus some extra synthesized ones on atkbd as an echo of actually changing the
--
1.6.0.2
^ permalink raw reply related
* Re: [PATCH] Add new DMI_VENDOR for MSI notebook in 95-keymap.rules
From: Martin Pitt @ 2010-09-25 9:36 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1285404627-25631-1-git-send-email-jlee@novell.com>
Hello Lee,
Lee, Chun-Yi [2010-09-25 16:50 +0800]:
> Add new DMI_VENDOR "Micro-Star International" in 95-keymap.rules,
> for enable the hotkey mapping.
Thanks! Committed, with some minor changelog cleanup.
BTW, for next time it is enough to just send the patch to the hotplug
mailing list.
Have a nice weekend,
Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
^ permalink raw reply
* Re: [PATCH] Add new DMI_VENDOR for MSI notebook in
From: Joey Lee @ 2010-09-25 13:37 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1285404627-25631-1-git-send-email-jlee@novell.com>
Hi Martin,
Got it! Thank's a lot! :-)
Joey Lee
於 六，2010-09-25 於 11:36 +0200，Martin Pitt 提到：
> Hello Lee,
>
> Lee, Chun-Yi [2010-09-25 16:50 +0800]:
> > Add new DMI_VENDOR "Micro-Star International" in 95-keymap.rules,
> > for enable the hotkey mapping.
>
> Thanks! Committed, with some minor changelog cleanup.
>
> BTW, for next time it is enough to just send the patch to the hotplug
> mailing list.
>
> Have a nice weekend,
>
> Martin
^ permalink raw reply
* Re: [ANNOUNCE] udev 152 release
From: Andreas Metzler @ 2010-10-03 6:55 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1271750116.2583.12.camel@yio.site>
Kay Sievers <kay.sievers <at> vrfy.org> writes:
[...]
> Here comes a new udev version.
[...]
> udev 152
[...]
> The option "all_partitions" was removed from udev. This should not be
> needed for usual hardware. Udev can not safely make assumptions
> about non-existing partition major/minor numbers, and therefore no
> longer provide this unreliable and unsafe option.
[...]
Hello,
is there a officially suggested replacement for "all_partitions"?
USB-cardreaders are not "unusual", but nevertheless usually do not report
media-changes (See
http://www.reactivated.net/writing_udev_rules.html#example-usbcardreader).
thanks, cu andreas
^ permalink raw reply
* Re: [ANNOUNCE] udev 152 release
From: Kay Sievers @ 2010-10-03 11:17 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1271750116.2583.12.camel@yio.site>
On Sun, Oct 3, 2010 at 08:55, Andreas Metzler
<ametzler@downhill.at.eu.org> wrote:
> Kay Sievers <kay.sievers <at> vrfy.org> writes:
> [...]
>> Here comes a new udev version.
> [...]
>> udev 152
> [...]
>> The option "all_partitions" was removed from udev. This should not be
>> needed for usual hardware. Udev can not safely make assumptions
>> about non-existing partition major/minor numbers, and therefore no
>> longer provide this unreliable and unsafe option.
> [...]
>
> is there a officially suggested replacement for "all_partitions"?
> USB-cardreaders are not "unusual", but nevertheless usually do not report
> media-changes (See
> http://www.reactivated.net/writing_udev_rules.html#example-usbcardreader).
No, not in udev. The main device node needs to be polled periodically.
This is usually done by udisks, a simple 'touch' will also do.
Currently it's being worked on to add polling to the kernel itself.
Kay
^ permalink raw reply
* Re: [ANNOUNCE] udev 152 release
From: Andreas Metzler @ 2010-10-03 11:59 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1271750116.2583.12.camel@yio.site>
Kay Sievers <kay.sievers@vrfy.org> wrote:
> On Sun, Oct 3, 2010 at 08:55, Andreas Metzler
> <ametzler@downhill.at.eu.org> wrote:
>> Kay Sievers <kay.sievers <at> vrfy.org> writes:
>> [...]
>>> Here comes a new udev version.
>> [...]
>>> udev 152
>> [...]
>>> The option "all_partitions" was removed from udev. This should not be
>>> needed for usual hardware. Udev can not safely make assumptions
>>> about non-existing partition major/minor numbers, and therefore no
>>> longer provide this unreliable and unsafe option.
>> [...]
>> is there a officially suggested replacement for "all_partitions"?
>> USB-cardreaders are not "unusual", but nevertheless usually do not report
>> media-changes (See
>> http://www.reactivated.net/writing_udev_rules.html#example-usbcardreader).
> No, not in udev. The main device node needs to be polled periodically.
> This is usually done by udisks, a simple 'touch' will also do.
> Currently it's being worked on to add polling to the kernel itself.
Isn't polling evil(TM)?
I would be (and was) perfectlywithe leightweight solution of of
automatically get /dev/sdX[1-8] and symlinks /dev/cardreader/sd[1-8]
instead of just /dev/sdX and the symlink /dev/cardreader/sd when udev
detects the presence of the cardreader device. Whether the number of
device nodes exactly matches the number of partitions on the inserted
sd-card is not really of importance for me.
cu andreas
^ permalink raw reply
* [ANNOUNCE] udev 163 release
From: Kay Sievers @ 2010-10-07 13:41 UTC (permalink / raw)
To: linux-hotplug
Here comes a new udev version. Thanks to all who have contributed to
this release.
The tarball can be found here:
ftp://ftp.kernel.org/pub/linux/utils/kernel/hotplug/
The development repository can be found here:
http://www.kernel.org/git/?p=linux/hotplug/udev.git;a=summary
The ChangeLog can be found here:
http://www.kernel.org/git/?p=linux/hotplug/udev.git;a=blob;hb=HEAD;f=ChangeLog
udev 163
====
Bugfixes.
^ permalink raw reply
* [PATCH V2] Use firmware provided index to register a network
From: Narendra_K @ 2010-10-07 14:23 UTC (permalink / raw)
To: netdev, linux-hotplug, linux-pci
Cc: Matt_Domsch, Jordan_Hargrave, Vijay_Nijhawan, Charles_Rose
Hello,
V1 -> V2:
This patch addresses the scenario of buggy firmware/BIOS tables. The
patch introduces a command line parameter 'no_netfwindex', passing which
firmware provided index will not be used to derive 'eth' names. By
default, firmware index will be used and the parameter can be used to
work around buggy firmware/BIOS tables.
Please find the patch below.
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.
Passing 'no_netfwindex' command line parameter would result in
firmware index not being used to derive the names as described above.
Signed-off-by: Narendra K <narendra_k@dell.com>
---
Documentation/kernel-parameters.txt | 6 +++++
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 | 42 ++++++++++++++++++++++++++++++-----
6 files changed, 51 insertions(+), 6 deletions(-)
diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index 3cdb4d8..73edbc0 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -1529,6 +1529,12 @@ and is between 256 and 4096 characters. It is defined in the file
This usage is only documented in each driver source
file if at all.
+ no_netfwindex [NET] Do not use firmware index to derive ethN names
+ Names for onboard network interfaces are derived from
+ the firmware provided index for these devices. Using
+ this parameter would result in firmware index not being
+ used to derive ethN names.
+
nf_conntrack.acct [NETFILTER] Enable connection tracking flow accounting
0 to disable accounting
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..f7982c4 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -853,9 +853,18 @@ int dev_valid_name(const char *name)
}
EXPORT_SYMBOL(dev_valid_name);
+int netdev_use_fwindex = 1;
+
+static int __init netdev_use_fwindex_to_register(char *str)
+{
+ netdev_use_fwindex = 0;
+ return 0;
+}
+early_param("no_netfwindex", netdev_use_fwindex_to_register);
+
/**
* __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 +877,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 +897,36 @@ static int __dev_alloc_name(struct net *net, const char *name, char *buf)
if (p[1] != 'd' || strchr(p + 2, '%'))
return -EINVAL;
+ if (likely(netdev_use_fwindex)) {
+ 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
+ */
+ if (likely(netdev_use_fwindex)) {
+ for (i = 0; i < pci_netdevs_with_fwindex; i++)
+ set_bit(i, inuse);
+ } else
+ pci_netdevs_with_fwindex = 0;
+
+ 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 +968,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
* Re: [PATCH] Use firmware provided index to register a network
From: Narendra_K @ 2010-10-07 14:26 UTC (permalink / raw)
To: greg
Cc: netdev, linux-hotplug, linux-pci, Matt_Domsch, Charles_Rose,
Jordan_Hargrave, Vijay_Nijhawan
In-Reply-To: <20100923163336.GA15603@kroah.com>
On Thu, Sep 23, 2010 at 10:03:36PM +0530, Greg KH wrote:
> 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?
>
It took some time to find out the details asked above. Right, windows
does not use SMBIOS type 41 record to derive names. But as a datapoint,
windows also has the same problem.
Yes, firmware and BIOS tables can be buggy. How about a command line
parameter 'no_netfwindex', passing which firmware index will not be
used to derive ethN names ? That would handle the scenario of buggy
firmware and names will be derived in the now existing way.
I will submit a patch shortly implementing this.
--
With regards,
Narendra K
^ permalink raw reply
* Re: [PATCH] Use firmware provided index to register a network interface
From: Tim Small @ 2010-10-07 14:27 UTC (permalink / raw)
To: Narendra_K
Cc: greg, netdev, linux-hotplug, linux-pci, Matt_Domsch, Charles_Rose,
Jordan_Hargrave, Vijay_Nijhawan
In-Reply-To: <20101007141433.GA2641@libnet-test.oslab.blr.amer.dell.com>
On 07/10/10 15:14, Narendra_K@Dell.com wrote:
> Yes, firmware and BIOS tables can be buggy. How about a command line
> parameter 'no_netfwindex', passing which firmware index will not be
> used to derive ethN names ? That would handle the scenario of buggy
> firmware and names will be derived in the now existing way.
>
> I will submit a patch shortly implementing this.
>
What was the reason for not doing this in user space again? You stated
that you got races when doing renames like eth0 -> eth2, but the
solution looked like renaming into a different name space such as eth0
-> ethlom2 etc. so that it wouldn't race with the names handed out by
the kernel?
Tim.
^ permalink raw reply
* Re: [PATCH] Use firmware provided index to register a network
From: Greg KH @ 2010-10-07 14:31 UTC (permalink / raw)
To: Narendra_K
Cc: netdev, linux-hotplug, linux-pci, Matt_Domsch, Charles_Rose,
Jordan_Hargrave, Vijay_Nijhawan
In-Reply-To: <20101007141433.GA2641@libnet-test.oslab.blr.amer.dell.com>
On Thu, Oct 07, 2010 at 07:44:57PM +0530, Narendra_K@Dell.com wrote:
> On Thu, Sep 23, 2010 at 10:03:36PM +0530, Greg KH wrote:
> > 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?
> >
>
> It took some time to find out the details asked above. Right, windows
> does not use SMBIOS type 41 record to derive names. But as a datapoint,
> windows also has the same problem.
If windows does not use this field, then you can guarantee it will show
up incorrectly in BIOSes and never be tested by manufacturers before
they ship their machines.
> Yes, firmware and BIOS tables can be buggy. How about a command line
> parameter 'no_netfwindex', passing which firmware index will not be
> used to derive ethN names ? That would handle the scenario of buggy
> firmware and names will be derived in the now existing way.
I'd prefer the option never be added in the first place as you are
placing a big burden on people whose machines were working properly on
old kernels, to suddenly have to add a command line option to get their
box to now work again.
And again, as this is a "simple" rename type operation, I still don't
see why you can't just do this from a udev rule, especially if the
firmware information is exported to userspace. That is where such
"policy" should be added, not within the kernel itself.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH V2] Use firmware provided index to register a network
From: Greg KH @ 2010-10-07 15:11 UTC (permalink / raw)
To: Narendra_K
Cc: netdev, linux-hotplug, linux-pci, Matt_Domsch, Jordan_Hargrave,
Vijay_Nijhawan, Charles_Rose
In-Reply-To: <20101007142319.GB2641@libnet-test.oslab.blr.amer.dell.com>
On Thu, Oct 07, 2010 at 07:23:35AM -0700, Narendra_K@Dell.com wrote:
> Hello,
>
> V1 -> V2:
>
> This patch addresses the scenario of buggy firmware/BIOS tables. The
> patch introduces a command line parameter 'no_netfwindex', passing which
> firmware provided index will not be used to derive 'eth' names. By
> default, firmware index will be used and the parameter can be used to
> work around buggy firmware/BIOS tables.
>
> Please find the patch below.
>
> 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.
No, this has the very big chance to reorder existing network names and
should all be done in userspace with the firmware information exported
in sysfs, if the user so desires.
So consider this patch rejected from me.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH V2] Use firmware provided index to register a network
From: Stephen Hemminger @ 2010-10-07 16:14 UTC (permalink / raw)
To: Narendra_K
Cc: netdev, linux-hotplug, linux-pci, Matt_Domsch, Jordan_Hargrave,
Vijay_Nijhawan, Charles_Rose
In-Reply-To: <20101007142319.GB2641@libnet-test.oslab.blr.amer.dell.com>
On Thu, 7 Oct 2010 07:23:35 -0700
<Narendra_K@Dell.com> wrote:
> Hello,
>
> V1 -> V2:
>
> This patch addresses the scenario of buggy firmware/BIOS tables. The
> patch introduces a command line parameter 'no_netfwindex', passing which
> firmware provided index will not be used to derive 'eth' names. By
> default, firmware index will be used and the parameter can be used to
> work around buggy firmware/BIOS tables.
>
> Please find the patch below.
>
> 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 -
I agree with Greg. Provide the firmware index in sysfs for use
in udev userspace and let udev do the policy on the naming.
The firmware index could be missing, wrong, or interesting on only
some devices.
^ permalink raw reply
* Re: [PATCH V2] Use firmware provided index to register a network interface
From: Matt Domsch @ 2010-10-07 16:31 UTC (permalink / raw)
To: Greg KH
Cc: Narendra_K, netdev, linux-hotplug, linux-pci, Jordan_Hargrave,
Vijay_Nijhawan, Charles_Rose
In-Reply-To: <20101007151134.GA25713@kroah.com>
On Thu, Oct 07, 2010 at 08:11:34AM -0700, Greg KH wrote:
> On Thu, Oct 07, 2010 at 07:23:35AM -0700, Narendra_K@Dell.com wrote:
> > Hello,
> >
> > V1 -> V2:
> >
> > This patch addresses the scenario of buggy firmware/BIOS tables. The
> > patch introduces a command line parameter 'no_netfwindex', passing which
> > firmware provided index will not be used to derive 'eth' names. By
> > default, firmware index will be used and the parameter can be used to
> > work around buggy firmware/BIOS tables.
> >
> > Please find the patch below.
> >
> > 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.
>
> No, this has the very big chance to reorder existing network names and
> should all be done in userspace with the firmware information exported
> in sysfs, if the user so desires.
Existing names that use 70-persistent-net.rules won't change. They
were non-deterministically assigned and recorded in that file, so
they'll persist. At most, they'll have to deal with the same
"eth0_rename" garbage that anyone wanting to get a consistent name
from other than MAC address would get. The only reason the
auto-created 70-persistent-net.rules works is that most people don't
change their NIC configuration after install, so it has no renaming to do.
The kernel patch has the advantage of not requiring users to change
their scripts, by reserving the first N values for onboard devices as
BIOS describes them.
Userspace udev rules require us to change user behavior, and likely
their scripts, to use a new namespace such as ethlom1, in order to get
deterministic naming.
> > It took some time to find out the details asked above. Right,
> > windows does not use SMBIOS type 41 record to derive names. But as
> > a datapoint, windows also has the same problem.
> If windows does not use this field, then you can guarantee it will
> show up incorrectly in BIOSes and never be tested by manufacturers
> before they ship their machines.
There are 2 methods of exporting the information that have gotten
confusing here.
1) SMBIOS type 41 method. Windows does not use this today, and I
can't speak to their future plans. Narendra's kernel patch does,
as has biosdevname, the udev helper we first wrote for this purpose, for several years.
2) soon-to-be-released PCIe Firmware Spec, exporting label and index
as an ACPI _DSM(). It is anticipated that Windows will use this
information in some fashion at some point, per our conversations
with Microsoft as part of the PCI SIG proposal process. We've held
off submitting a kernel patch until the spec is public.
Cases:
1) BIOS doesn't provide this information (the common case today for
all but Dell 10G and newer servers), nothing is reserved, and
therefore the existing 70-persistent-net.rules take effect to name
devices. No change in behavior for existing systems. New installs
will have NICs named non-deterministically, and recorded in
70-persistent-net.rules. Users desiring consistent naming must
adjust 70-persistent-net.rules after install, and to avoid
eth0_rename collisions, must rename into another namespace.
2) BIOS provides this information correctly (Dell 10G and newer servers, or
anyone else implementing the spec). The first N values for onboard
devices are reserved and assigned by the kernel to onboard
devices. 70-persistent-net.rules may still try to rename the
ports, and may fail with eth0_rename collisions. Users would have
to adjust 70-persistent-net.rules to accommodate, but they do not
have to change the namespace from ethX to something else. New
installs will have onboard NICs named deterministically, and recorded in
70-persistent-net.rules.
3) BIOS provides this information incorrectly (none known today).
Some number of N values may be reserved, more or fewer than
actually present. In either case, it's possible that
70-persistent-net.rules would have to be adjusted to accommodate,
but they do not have to change the namespace from ethX to something
else. New installs will have onboard NICs named deterministically,
if not ideally due to buggy BIOS, and recorded in
70-persistent-net.rules.
What I can't find here is a solution where the user gets determistic
naming, without being forced to change the namespace and adjust their
scripts. Can anyone? I'm not opposed to "do it all in userspace" -
really, I'm not. But the 'where' is only part of the problem. No
userspace solution has yet been proposed that doesn't require a
namespace change, and I'm still hoping to avoid that.
Thanks,
Matt
--
Matt Domsch
Technology Strategist
Dell | Office of the CTO
^ permalink raw reply
* Re: [PATCH V2] Use firmware provided index to register a network
From: Greg KH @ 2010-10-07 16:48 UTC (permalink / raw)
To: Matt Domsch
Cc: Narendra_K, netdev, linux-hotplug, linux-pci, Jordan_Hargrave,
Vijay_Nijhawan, Charles_Rose
In-Reply-To: <20101007163113.GA14260@auslistsprd01.us.dell.com>
On Thu, Oct 07, 2010 at 11:31:13AM -0500, Matt Domsch wrote:
> On Thu, Oct 07, 2010 at 08:11:34AM -0700, Greg KH wrote:
> > On Thu, Oct 07, 2010 at 07:23:35AM -0700, Narendra_K@Dell.com wrote:
> > > Hello,
> > >
> > > V1 -> V2:
> > >
> > > This patch addresses the scenario of buggy firmware/BIOS tables. The
> > > patch introduces a command line parameter 'no_netfwindex', passing which
> > > firmware provided index will not be used to derive 'eth' names. By
> > > default, firmware index will be used and the parameter can be used to
> > > work around buggy firmware/BIOS tables.
> > >
> > > Please find the patch below.
> > >
> > > 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.
> >
> > No, this has the very big chance to reorder existing network names and
> > should all be done in userspace with the firmware information exported
> > in sysfs, if the user so desires.
>
> Existing names that use 70-persistent-net.rules won't change.
But users that don't use it would cause their names to change, and you
can't break that, no matter how naturally fragile those types of systems
are. Sorry.
> The kernel patch has the advantage of not requiring users to change
> their scripts, by reserving the first N values for onboard devices as
> BIOS describes them.
So you feel that updating a kernel is easier than getting a user to
update their userspace scripts? While I might also feel it is that way,
in reality, it isn't, sorry.
> Userspace udev rules require us to change user behavior, and likely
> their scripts, to use a new namespace such as ethlom1, in order to get
> deterministic naming.
Then use that, don't put this in the kernel please.
> > > It took some time to find out the details asked above. Right,
> > > windows does not use SMBIOS type 41 record to derive names. But as
> > > a datapoint, windows also has the same problem.
>
> > If windows does not use this field, then you can guarantee it will
> > show up incorrectly in BIOSes and never be tested by manufacturers
> > before they ship their machines.
>
> There are 2 methods of exporting the information that have gotten
> confusing here.
>
> 1) SMBIOS type 41 method. Windows does not use this today, and I
> can't speak to their future plans. Narendra's kernel patch does,
> as has biosdevname, the udev helper we first wrote for this
> purpose, for several years.
Then stick with that udev helper please :)
> 2) soon-to-be-released PCIe Firmware Spec, exporting label and index
> as an ACPI _DSM(). It is anticipated that Windows will use this
> information in some fashion at some point, per our conversations
> with Microsoft as part of the PCI SIG proposal process. We've held
> off submitting a kernel patch until the spec is public.
Let's worry about that _when_ it is public, and when there is a Windows
version that supports it please. Until then, there will not be support
for this in BIOSes in any usable way.
> Cases:
> 1) BIOS doesn't provide this information (the common case today for
> all but Dell 10G and newer servers), nothing is reserved, and
> therefore the existing 70-persistent-net.rules take effect to name
> devices. No change in behavior for existing systems. New installs
> will have NICs named non-deterministically, and recorded in
> 70-persistent-net.rules. Users desiring consistent naming must
> adjust 70-persistent-net.rules after install, and to avoid
> eth0_rename collisions, must rename into another namespace.
That's fine and is how things work today, right?
> 2) BIOS provides this information correctly (Dell 10G and newer servers, or
> anyone else implementing the spec). The first N values for onboard
> devices are reserved and assigned by the kernel to onboard
> devices.
And you just broke people's machines that don't use udev for network
naming. Sorry, that's not going to work.
> 70-persistent-net.rules may still try to rename the
> ports, and may fail with eth0_rename collisions.
So you just broke their machines as well, when it was working, again,
not acceptable.
> 3) BIOS provides this information incorrectly (none known today).
Only because we have no way of testing for this :)
> What I can't find here is a solution where the user gets determistic
> naming, without being forced to change the namespace and adjust their
> scripts. Can anyone?
No, and they shoudn't.
You should only have "deterministic" naming if you want it, and you set
it up to do so, from userspace. The kernel is not responsible for this,
sorry.
If you want to do it in userspace, you have all the tools, and the data
exported from the kernel to do so.
> I'm not opposed to "do it all in userspace" - really, I'm not. But
> the 'where' is only part of the problem. No userspace solution has
> yet been proposed that doesn't require a namespace change, and I'm
> still hoping to avoid that.
Just use a new script for people who want this, they will have to know
they want it anyway, right?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH V2] Use firmware provided index to register a network
From: David Lamparter @ 2010-10-07 16:49 UTC (permalink / raw)
To: Matt Domsch
Cc: Greg KH, Narendra_K, netdev, linux-hotplug, linux-pci,
Jordan_Hargrave, Vijay_Nijhawan, Charles_Rose
In-Reply-To: <20101007163113.GA14260@auslistsprd01.us.dell.com>
Hi Matt,
On Thu, Oct 07, 2010 at 11:31:13AM -0500, Matt Domsch wrote:
> At most, they'll have to deal with the same "eth0_rename"
Getting that "eth0_rename" stuff is not something unchangeably imposed
by the kernel. I think this should be considered an udev bug most of all
things, since if the udev scripts did it right, this wouldn't happen. A
"right" way to do this would for example be to first rename all devices
to "tmpwhatever0", then rename them back to their proper ethX names.
Now I don't know even a single bit about udev scripting, so maybe this
isn't possible with the current udev infrastructure, but there's
certainly no kernel part stopping a proper implementation.
Btw, what happened to nameif(8)? It's totally outdated (and deprecated I
guess?), but it got the job done...
-David
^ permalink raw reply
* Re: [PATCH V2] Use firmware provided index to register a network interface
From: Kay Sievers @ 2010-10-07 17:05 UTC (permalink / raw)
To: Greg KH
Cc: Matt Domsch, Narendra_K, netdev, linux-hotplug, linux-pci,
Jordan_Hargrave, Vijay_Nijhawan, Charles_Rose
In-Reply-To: <20101007164835.GA27339@kroah.com>
On Thu, Oct 7, 2010 at 18:48, Greg KH <greg@kroah.com> wrote:
> On Thu, Oct 07, 2010 at 11:31:13AM -0500, Matt Domsch wrote:
>> 1) SMBIOS type 41 method. Windows does not use this today, and I
>> can't speak to their future plans. Narendra's kernel patch does,
>> as has biosdevname, the udev helper we first wrote for this
>> purpose, for several years.
>
> Then stick with that udev helper please :)
What about just exporting this information in sysfs, and not touch the naming?
Anyway, I'm pretty sure all of this naming of onboard devices should
happen only at install time, or from a system management tool and not
at hotplug time.
We should not get confused by the way the (very simple)
automatic-rule-creater for persistent netdev naming in udev works.
This is really just a tool for the common case, and works fine for the
majority of people.
I'm not sure, if we should put all these special use cases in the
hotplug path. I mean it's not that people add and remove 4 port
network cards with special BIOS all the time, and expect proper naming
on the first bootup, right? The installer, or the system management
tool could just create/edit udev rules to provide proper device naming
on whatever property is available at a specific hardware, be it the
MAC address or some other persistent match?
Kay
^ permalink raw reply
* Re: [PATCH V2] Use firmware provided index to register a network interface
From: Kay Sievers @ 2010-10-07 17:13 UTC (permalink / raw)
To: David Lamparter
Cc: Matt Domsch, Greg KH, Narendra_K, netdev, linux-hotplug,
linux-pci, Jordan_Hargrave, Vijay_Nijhawan, Charles_Rose
In-Reply-To: <20101007164906.GB122295@jupiter.n2.diac24.net>
On Thu, Oct 7, 2010 at 18:49, David Lamparter <equinox@diac24.net> wrote:
> On Thu, Oct 07, 2010 at 11:31:13AM -0500, Matt Domsch wrote:
>> At most, they'll have to deal with the same "eth0_rename"
>
> Getting that "eth0_rename" stuff is not something unchangeably imposed
> by the kernel. I think this should be considered an udev bug most of all
> things, since if the udev scripts did it right, this wouldn't happen. A
> "right" way to do this would for example be to first rename all devices
> to "tmpwhatever0", then rename them back to their proper ethX names.
Whats the difference between eth0_rename and tmpeth0? I don't see any. :)
> Now I don't know even a single bit about udev scripting, so maybe this
> isn't possible with the current udev infrastructure, but there's
> certainly no kernel part stopping a proper implementation.
>
> Btw, what happened to nameif(8)? It's totally outdated (and deprecated I
> guess?), but it got the job done...
It can't swap already taken device names on hotplug, and that job
might get complicated very easily. Also stuff needs to be renamed
before the device is announced to userspace, otherwise the interface
gets configured and can't be renamed anymore.
Kay
^ permalink raw reply
* Re: [PATCH V2] Use firmware provided index to register a network
From: Greg KH @ 2010-10-07 17:15 UTC (permalink / raw)
To: Kay Sievers
Cc: Matt Domsch, Narendra_K, netdev, linux-hotplug, linux-pci,
Jordan_Hargrave, Vijay_Nijhawan, Charles_Rose
In-Reply-To: <AANLkTinP5WPDPvk+kq8vsyP=xC9qcoe+c=1EBp0XJNPk@mail.gmail.com>
On Thu, Oct 07, 2010 at 07:05:14PM +0200, Kay Sievers wrote:
> On Thu, Oct 7, 2010 at 18:48, Greg KH <greg@kroah.com> wrote:
> > On Thu, Oct 07, 2010 at 11:31:13AM -0500, Matt Domsch wrote:
> >> 1) SMBIOS type 41 method. Windows does not use this today, and I
> >> can't speak to their future plans. Narendra's kernel patch does,
> >> as has biosdevname, the udev helper we first wrote for this
> >> purpose, for several years.
> >
> > Then stick with that udev helper please :)
>
> What about just exporting this information in sysfs, and not touch the naming?
I think this is now exported in userspace, right Narendra?
> Anyway, I'm pretty sure all of this naming of onboard devices should
> happen only at install time, or from a system management tool and not
> at hotplug time.
>
> We should not get confused by the way the (very simple)
> automatic-rule-creater for persistent netdev naming in udev works.
> This is really just a tool for the common case, and works fine for the
> majority of people.
>
> I'm not sure, if we should put all these special use cases in the
> hotplug path. I mean it's not that people add and remove 4 port
> network cards with special BIOS all the time, and expect proper naming
> on the first bootup, right? The installer, or the system management
> tool could just create/edit udev rules to provide proper device naming
> on whatever property is available at a specific hardware, be it the
> MAC address or some other persistent match?
I totally agree.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH V2] Use firmware provided index to register a network
From: Narendra_K @ 2010-10-07 17:56 UTC (permalink / raw)
To: greg
Cc: kay.sievers, Matt_Domsch, netdev, linux-hotplug, linux-pci,
Jordan_Hargrave, Vijay_Nijhawan, Charles_Rose
In-Reply-To: <20101007171532.GA29857@kroah.com>
On Thu, Oct 07, 2010 at 10:45:32PM +0530, Greg KH wrote:
> On Thu, Oct 07, 2010 at 07:05:14PM +0200, Kay Sievers wrote:
> > On Thu, Oct 7, 2010 at 18:48, Greg KH <greg@kroah.com> wrote:
> > > On Thu, Oct 07, 2010 at 11:31:13AM -0500, Matt Domsch wrote:
> > >> 1) SMBIOS type 41 method. Windows does not use this today, and I
> > >> can't speak to their future plans. Narendra's kernel patch does,
> > >> as has biosdevname, the udev helper we first wrote for this
> > >> purpose, for several years.
> > >
> > > Then stick with that udev helper please :)
> >
> > What about just exporting this information in sysfs, and not touch the
> naming?
>
> I think this is now exported in userspace, right Narendra?
>
Right. It is in the mainline kernel.
( commit 911e1c9b05a8e3559a7aa89083930700a0b9e7ee)
--
With regards,
Narendra K
^ permalink raw reply
* Re: [PATCH V2] Use firmware provided index to register a network
From: Narendra_K @ 2010-10-07 18:44 UTC (permalink / raw)
To: kay.sievers
Cc: greg, Matt_Domsch, netdev, linux-hotplug, linux-pci,
Jordan_Hargrave, Vijay_Nijhawan, Charles_Rose
In-Reply-To: <AANLkTinP5WPDPvk+kq8vsyP=xC9qcoe+c=1EBp0XJNPk@mail.gmail.com>
On Thu, Oct 07, 2010 at 10:35:14PM +0530, Kay Sievers wrote:
> On Thu, Oct 7, 2010 at 18:48, Greg KH <greg@kroah.com> wrote:
> > On Thu, Oct 07, 2010 at 11:31:13AM -0500, Matt Domsch wrote:
> >> 1) SMBIOS type 41 method. Windows does not use this today, and I
> >> can't speak to their future plans. Narendra's kernel patch does,
> >> as has biosdevname, the udev helper we first wrote for this
> >> purpose, for several years.
> >
> > Then stick with that udev helper please :)
>
> What about just exporting this information in sysfs, and not touch the
> naming?
>
> Anyway, I'm pretty sure all of this naming of onboard devices should
> happen only at install time, or from a system management tool and not
> at hotplug time.
>
> We should not get confused by the way the (very simple)
> automatic-rule-creater for persistent netdev naming in udev works.
> This is really just a tool for the common case, and works fine for the
> majority of people.
Right. It works as the automatic rule creator saves the snapshot of the
registered network interfaces at run time.
>
> I'm not sure, if we should put all these special use cases in the
> hotplug path. I mean it's not that people add and remove 4 port
> network cards with special BIOS all the time, and expect proper naming
> on the first bootup, right? The installer, or the system management
> tool could just create/edit udev rules to provide proper device naming
> on whatever property is available at a specific hardware, be it the
> MAC address or some other persistent match?
>
The proposal made is not expecting deterministic naming when an add-in
card with 'N' ports is plugged in/out. It is specific to onboard devices
only. Expectation is onboard devices have deterministic naming at first
bootup. And no special BIOS required as SMBIOS tables are in use for
sometime now.
I did explore using rules based on the exported attribute ATTRS{index}
on a system with 4 Onboard devices and two add-in devices.(where add-in
device becomes eth0 and eth1)
# PCI device 0x14e4:0x164c (bnx2) (custom name provided by external
# tool) SUBSYSTEM="net", ACTION="add", DRIVERS="?*",
# ATTRS{index}="1", ATTR{type}="1", KERNEL="eth*", NAME="eth0"
(and similary for eth1..eth3)
And for add-in devices.
# 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" (and similar for eth5 as they do not have an index)
This works as i edited the file manually.
If this has to be done on a large number of systems where an image
based deployment is preferred, getting onboard device names as expected
is an issue and is important.
--
With regards,
Narendra K
^ permalink raw reply
* Restricting USB access
From: Ryan Lawrie @ 2010-10-07 19:50 UTC (permalink / raw)
To: linux-hotplug
Good afternoon,
Just wondering if I could get your assistance with something.
I need to secure the USB ports on my LAN workstations so they are not
writable by users (other than a certain group that I specify). Is this type
of restriction possible using udev rules?
I was using PolicyKit before but since we've changed OS (from openSUSE11.0
to 64-bit openSUSE11.2) that no longer seems to function properly.
Everybody has access to the USB ports now.
Any assistance you can offer would be greatly appreciated.
Take care,
Ryan Lawrie
^ permalink raw reply
* Re: [PATCH V2] Use firmware provided index to register a network
From: Matt Domsch @ 2010-10-07 20:42 UTC (permalink / raw)
To: Kay Sievers
Cc: Greg KH, K, Narendra, netdev@vger.kernel.org,
linux-hotplug@vger.kernel.org, linux-pci@vger.kernel.org,
Hargrave, Jordan, Nijhawan, Vijay, Rose, Charles
In-Reply-To: <AANLkTinP5WPDPvk+kq8vsyP=xC9qcoe+c=1EBp0XJNPk@mail.gmail.com>
On Thu, Oct 07, 2010 at 10:05:14AM -0700, Kay Sievers wrote:
> On Thu, Oct 7, 2010 at 18:48, Greg KH <greg@kroah.com> wrote:
> > On Thu, Oct 07, 2010 at 11:31:13AM -0500, Matt Domsch wrote:
> >> 1) SMBIOS type 41 method. Windows does not use this today, and I
> >> can't speak to their future plans. Narendra's kernel patch does,
> >> as has biosdevname, the udev helper we first wrote for this
> >> purpose, for several years.
> >
> > Then stick with that udev helper please :)
>
> What about just exporting this information in sysfs, and not touch the naming?
The config tools all take a netdevice name as their argument. What
would it look like then?
$ ifconfig $(netdevname 'Embedded NIC 1')
repeat for each tool that's called? This is similar to what we
proposed with the userspace patch and libnetdevname, so the lookup can
happen inside each app, rather than the system admin having to do the
translation themselves. That was rejected too...
otherwise, it's up to a human to do the translation in their head,
which isn't script-friendly.
-Matt
--
Matt Domsch
Technology Strategist
Dell | Office of the CTO
^ permalink raw reply
* Re: Restricting USB access
From: Greg KH @ 2010-10-07 20:50 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <OFACC41AE7.587D1697-ON852577B5.006C93B7-852577B5.006D0ACC@hc-sc.gc.ca>
On Thu, Oct 07, 2010 at 03:50:55PM -0400, Ryan Lawrie wrote:
>
> Good afternoon,
>
> Just wondering if I could get your assistance with something.
>
> I need to secure the USB ports on my LAN workstations so they are not
> writable by users (other than a certain group that I specify). Is this type
> of restriction possible using udev rules?
USB ports are "writeable" or "readable", it depends on the devices you
plug into them that you could then read or write to.
> I was using PolicyKit before but since we've changed OS (from openSUSE11.0
> to 64-bit openSUSE11.2) that no longer seems to function properly.
> Everybody has access to the USB ports now.
You might want to just restrict the users for the specific devices using
a udev rule, or policykit, if that's still around.
What types of devices are you trying to restrict?
thanks,
greg k-h
^ 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