: Proposed F19 Feature: systemd/udev Predictable Network
Interface Names
On 03/04/2013 04:01 PM, Matt Domsch wrote:
drivers/net/ethernet/sfc/siena.c: efx-net_dev-dev_id =
EFX_OWORD_FIELD(reg, FRF_CZ_CS_PORT_NUM) - 1;
I think sfc does not really *need* to set dev_id.
Yes
On Tue, Mar 5, 2013 at 5:52 PM, Michal Schmidt mschm...@redhat.com wrote:
On 03/04/2013 04:01 PM, Matt Domsch wrote:
drivers/net/ethernet/sfc/siena.c: efx-net_dev-dev_id =
EFX_OWORD_FIELD(reg, FRF_CZ_CS_PORT_NUM) - 1;
I think sfc does not really *need* to set dev_id.
Yes, these are
-Original Message-
From: devel-boun...@lists.fedoraproject.org [mailto:devel-
boun...@lists.fedoraproject.org] On Behalf Of Michal Schmidt
Sent: Tuesday, March 05, 2013 10:22 PM
To: devel@lists.fedoraproject.org
Subject: Re: Proposed F19 Feature: systemd/udev Predictable Network
On 03/04/2013 04:01 PM, Matt Domsch wrote:
drivers/net/ethernet/sfc/siena.c: efx-net_dev-dev_id =
EFX_OWORD_FIELD(reg, FRF_CZ_CS_PORT_NUM) - 1;
I think sfc does not really *need* to set dev_id.
Yes, these are multi-port cards, but the ports are on distinct PCI
functions.
Michal
--
On Mon, Feb 25, 2013 at 11:02:55AM -0600, Andy Gospodarek wrote:
On Sat, Feb 23, 2013 at 10:28:21AM +0100, Bill Nottingham wrote:
Matt Domsch (matt_dom...@dell.com) said:
On Wed, Feb 13, 2013 at 01:57:42PM -0600, Bill Nottingham wrote:
If we can solve the installtime naming convention
On Thu, Feb 28, 2013 at 09:20:51AM -0600, John Reiser wrote:
On 02/28/2013 06:55 AM, Kay Sievers wrote:
On Mon, Feb 25, 2013 at 6:02 PM, Andy Gospodarek agosp...@redhat.com
wrote:
I'd like to see kernel driver work to be sure every multi-port driver
with the same PCI b/d/b/f sets
On Mon, Mar 04, 2013 at 08:44:55AM -0600, Domsch, Matt wrote:
On Mon, Feb 25, 2013 at 11:02:55AM -0600, Andy Gospodarek wrote:
On Sat, Feb 23, 2013 at 10:28:21AM +0100, Bill Nottingham wrote:
Matt Domsch (matt_dom...@dell.com) said:
On Wed, Feb 13, 2013 at 01:57:42PM -0600, Bill
On Mon, Mar 04, 2013 at 09:01:35AM -0600, Matt Domsch wrote:
On Mon, Mar 04, 2013 at 08:44:55AM -0600, Domsch, Matt wrote:
On Mon, Feb 25, 2013 at 11:02:55AM -0600, Andy Gospodarek wrote:
On Sat, Feb 23, 2013 at 10:28:21AM +0100, Bill Nottingham wrote:
Matt Domsch (matt_dom...@dell.com)
On Mon, Mar 04, 2013 at 10:03:01AM -0600, Andy Gospodarek wrote:
On Mon, Mar 04, 2013 at 09:01:35AM -0600, Matt Domsch wrote:
On Mon, Mar 04, 2013 at 08:44:55AM -0600, Domsch, Matt wrote:
The challenge here is that because struct netdev is initialized to all
zeros, code that consumes
On Mon, Mar 04, 2013 at 10:19:14AM -0600, Matt Domsch wrote:
On Mon, Mar 04, 2013 at 10:03:01AM -0600, Andy Gospodarek wrote:
On Mon, Mar 04, 2013 at 09:01:35AM -0600, Matt Domsch wrote:
On Mon, Mar 04, 2013 at 08:44:55AM -0600, Domsch, Matt wrote:
The challenge here is that because
On Mon, Mar 4, 2013 at 6:01 PM, Andy Gospodarek agosp...@redhat.com wrote:
On Mon, Mar 04, 2013 at 10:19:14AM -0600, Matt Domsch wrote:
drivers/net/ethernet/mellanox/mlx4/en_netdev.c: dev-dev_id = port - 1;
drivers/net/ethernet/sfc/siena.c: efx-net_dev-dev_id =
Kay Sievers (k...@vrfy.org) said:
On Mon, Feb 25, 2013 at 6:02 PM, Andy Gospodarek agosp...@redhat.com wrote:
I'd like to see kernel driver work to be sure every multi-port driver
with the same PCI b/d/b/f sets dev_id. That isn't necessarily true
today, which makes it hard to trust.
On Mon, Feb 25, 2013 at 6:02 PM, Andy Gospodarek agosp...@redhat.com wrote:
I'd like to see kernel driver work to be sure every multi-port driver
with the same PCI b/d/b/f sets dev_id. That isn't necessarily true
today, which makes it hard to trust. biosdevname needs this too,
until
On 02/28/2013 06:55 AM, Kay Sievers wrote:
On Mon, Feb 25, 2013 at 6:02 PM, Andy Gospodarek agosp...@redhat.com wrote:
I'd like to see kernel driver work to be sure every multi-port driver
with the same PCI b/d/b/f sets dev_id. That isn't necessarily true
today, which makes it hard to
On Sat, Feb 23, 2013 at 10:28:21AM +0100, Bill Nottingham wrote:
Matt Domsch (matt_dom...@dell.com) said:
On Wed, Feb 13, 2013 at 01:57:42PM -0600, Bill Nottingham wrote:
If we can solve the installtime naming convention choice to not
eliminate biosdevname, be able to disable
Matt Domsch (matt_dom...@dell.com) said:
On Wed, Feb 13, 2013 at 01:57:42PM -0600, Bill Nottingham wrote:
If we can solve the installtime naming convention choice to not
eliminate biosdevname, be able to disable systemd/udevd naming, and
have the default be possible on a
On Wed, Feb 13, 2013 at 01:57:42PM -0600, Bill Nottingham wrote:
If we can solve the installtime naming convention choice to not
eliminate biosdevname, be able to disable systemd/udevd naming, and
have the default be possible on a per-system-vendor basis, and solve
the NPAR/SR-IOV/Mellanox
Matt Domsch (matt_dom...@dell.com) said:
The RHEL model of disabling biosdevname by some hardware
vendors, at installtime, is not accounted for in the current proposal.
I find this model pretty broken - if we want to have clear semantics
that are easily explainable to users and admins, we
On Thu, Feb 07, 2013 at 09:22:40PM -0600, Kay Sievers wrote:
On Thu, Feb 7, 2013 at 7:12 AM, Matt Domsch matt_dom...@dell.com wrote:
We
will need a method to enable/disable on a per-vendor basis as we
added to RHEL in the udev rules that invoke (or don't) biosdevname.
The
On Tue, Feb 12, 2013 at 4:44 PM, Matt Domsch matt_dom...@dell.com wrote:
I am concerned about the naming convention at installtime. The
current proposal removes biosdevname from comps @core as mandatory,
and I presume would also remove it from the anaconda install
environment as well. This
On Thu, Feb 7, 2013 at 7:12 AM, Matt Domsch matt_dom...@dell.com wrote:
We
will need a method to enable/disable on a per-vendor basis as we
added to RHEL in the udev rules that invoke (or don't) biosdevname.
The suggestion of linking in (or not) rules files won't work for a
On 02/05/2013 02:53 AM, Scott Schmit wrote:
Is there a program/script we can run that would tell us what the
interface names would be without biosdevname (without running the new
version of systemd on the box)?
If you have Fedora 18 with updates applied your systemd is new enough to
allow
On 2-6-13 14:33:42 Michal Schmidt wrote:
If you have Fedora 18 with updates applied your systemd is new
enough to allow you to see the udev-generated names using:
udevadm info --export -p /sys/class/net/$IFACE | grep ID_NET
Example output:
E: ID_NET_NAME_MAC=enx000f53014229
E:
I haven't chimed in on this thread yet, and as the original
biosdevname author, I suppose I should. Some points of consideration,
which I had shared with Lennart and Kay when they first showed me
their work.
A) I'm glad to see someone else recognize and want to tackle
this. Doing it in udev
On Mon, Feb 04, 2013 at 03:03:08PM +0100, Kay Sievers wrote:
On Thu, Jan 31, 2013 at 2:45 PM, Scott Schmit wrote:
Current:
em1 - enp2s0
That is expected, and actually the right thing to do. Udev cannot
apply such it looks like it is embedded heuristics for very
practical technical
On Thu, Jan 31, 2013 at 2:45 PM, Scott Schmit i.g...@comcast.net wrote:
Current:
em1 - enp2s0
That is expected, and actually the right thing to do. Udev cannot
apply such it looks like it is embedded heuristics for very
practical technical reasons. There is no reliable information about
that
On Tue, Jan 29, 2013 at 01:58:30PM -0500, Bill Nottingham wrote:
Tomasz Torcz (to...@pipebreaker.pl) said:
It might be worth considering that we keep the one special case and
change the 'eno' prefix in udev to 'em'... this will help some.
This could be dangerous. If I understand
Am 29.01.2013 19:38, schrieb Matthew Garrett:
On Tue, Jan 29, 2013 at 12:32:30PM -0600, Dan Williams wrote:
Except then you run into phones or WWAN cards that show up as Ethernet
devices, but aren't really Ethernet but just IP-in-8023-frames because
that was easier to do on Windows. That
On Fri, Jan 25, 2013 at 4:25 PM, Marcela Mašláňová mmasl...@redhat.com wrote:
On 01/25/2013 12:17 AM, Adam Williamson wrote:
On Thu, 2013-01-24 at 23:03 +, Jóhann B. Guðmundsson wrote:
It's best to rip the bandage of this in one release.
The churn from this should have been more or less
On Tue, Jan 29, 2013 at 06:20:20PM +0100, Miloslav Trmač wrote:
It's not only em1 mistakenly hard-coded in applications; it's user's
saved configuration, scripts etc., where often there is no practical
alternative to hard-coding.
Right; people who just converted all of their stuff to use this
On 01/29/2013 05:20 PM, Miloslav Trmač wrote:
On Fri, Jan 25, 2013 at 4:25 PM, Marcela Mašláňová mmasl...@redhat.com wrote:
On 01/25/2013 12:17 AM, Adam Williamson wrote:
On Thu, 2013-01-24 at 23:03 +, Jóhann B. Guðmundsson wrote:
It's best to rip the bandage of this in one release.
The
Miloslav Trmač (m...@volny.cz) said:
That's always the hope, and then we meet the cold reality, where someone
just patched 'em1' into everything and hoped that was good enough. But
sure, 'damn the torpedoes' is a viable approach too. I guess I was just
kind of hoping F19 would be a
On Tue, Jan 29, 2013 at 6:35 PM, Jóhann B. Guðmundsson
johan...@gmail.com wrote:
For the first how many users did you notice complaining about the biosdevice
name change, secondly are you seriously saying that if I have a local script
as in nothing we ship we just hold the presses and nothing
On Tue, 29.01.13 18:20, Miloslav Trmač (m...@volny.cz) wrote:
On Fri, Jan 25, 2013 at 4:25 PM, Marcela Mašláňová mmasl...@redhat.com
wrote:
On 01/25/2013 12:17 AM, Adam Williamson wrote:
On Thu, 2013-01-24 at 23:03 +, Jóhann B. Guðmundsson wrote:
It's best to rip the bandage of
On Tue, Jan 29, 2013 at 06:20:20PM +0100, Miloslav Trmač wrote:
It's not only em1 mistakenly hard-coded in applications; it's user's
saved configuration, scripts etc., where often there is no practical
alternative to hard-coding.
I created a bug report about this issue:
On Tue, Jan 29, 2013 at 12:05:44PM -0600, Andrew McNabb wrote:
I suppose I could have written a script that goes through the list of
interfaces, filters out hardcoded names like lo, wlan, tun, and
tap, and then assumes that whatever is left is the ethernet device.
And then I could have fixed
On 01/29/2013 01:13 PM, Andrew McNabb wrote:
On Tue, Jan 29, 2013 at 06:11:19PM +, Matthew Garrett wrote:
Walk /sys/class/net, filter on type, filter out bridges, filter out
wireless if you want to. sysfs should have all the information you need
without name-based heuristics.
You have
On Tue, Jan 29, 2013 at 12:13:37PM -0600, Andrew McNabb wrote:
On Tue, Jan 29, 2013 at 06:11:19PM +, Matthew Garrett wrote:
Walk /sys/class/net, filter on type, filter out bridges, filter out
wireless if you want to. sysfs should have all the information you need
without name-based
On Tue, 2013-01-29 at 18:29 +, Matthew Garrett wrote:
On Tue, Jan 29, 2013 at 12:13:37PM -0600, Andrew McNabb wrote:
On Tue, Jan 29, 2013 at 06:11:19PM +, Matthew Garrett wrote:
Walk /sys/class/net, filter on type, filter out bridges, filter out
wireless if you want to. sysfs
On Tue, Jan 29, 2013 at 12:32:30PM -0600, Dan Williams wrote:
Except then you run into phones or WWAN cards that show up as Ethernet
devices, but aren't really Ethernet but just IP-in-8023-frames because
that was easier to do on Windows. That one is quite fun, and there's no
good way to
On Tue, Jan 29, 2013 at 06:29:35PM +, Matthew Garrett wrote:
What is The ethernet device? It's the device that speaks ethernet and
which isn't wireless or a bridge. The correct way to identify it is to
look for devices that speak ethernet and which aren't wireless or
bridges.
I can
On Tue, Jan 29, 2013 at 12:46:29PM -0500, Bill Nottingham wrote:
Miloslav Trmač (m...@volny.cz) said:
That's always the hope, and then we meet the cold reality, where someone
just patched 'em1' into everything and hoped that was good enough. But
sure, 'damn the torpedoes' is a viable
Tomasz Torcz (to...@pipebreaker.pl) said:
It might be worth considering that we keep the one special case and
change the 'eno' prefix in udev to 'em'... this will help some.
This could be dangerous. If I understand right, there is not guarantee
em1 would become eno1 in 100% of cases.
On Tue, 2013-01-29 at 18:38 +, Matthew Garrett wrote:
On Tue, Jan 29, 2013 at 12:32:30PM -0600, Dan Williams wrote:
Except then you run into phones or WWAN cards that show up as Ethernet
devices, but aren't really Ethernet but just IP-in-8023-frames because
that was easier to do on
On Tue, Jan 29, 2013 at 12:46:29PM -0500, Bill Nottingham wrote:
It might be worth considering that we keep the one special case and
change the 'eno' prefix in udev to 'em'... this will help some.
Yes! Very much!
Not only will this practically easy things, it shifts the perception from
And
On 01/25/2013 04:25 PM, Marcela Mašláňová wrote:
I agree. The scope says no impact, but who knows how many packages
depend on hardcoded names.
I hope most of them has been already fixed with
https://bugzilla.redhat.com/show_bug.cgi?id=682334
--
Jiri
--
devel mailing list
Le lundi 28 janvier 2013 à 10:49 +0100, Jiri Popelka a écrit :
On 01/25/2013 04:25 PM, Marcela Mašláňová wrote:
I agree. The scope says no impact, but who knows how many packages
depend on hardcoded names.
I hope most of them has been already fixed with
Oron Peled (o...@actcom.co.il) said:
IMO, my following proposal is only feasible if (and it's a big iff),
the number of system calls and library functions that accept a network
interface name is not large [things like if_nameindex(), the ifreq
ioctl()'s, etc.]
If that's the case, we can
Jiri Popelka (jpope...@redhat.com) said:
On 01/25/2013 04:25 PM, Marcela Mašláňová wrote:
I agree. The scope says no impact, but who knows how many packages
depend on hardcoded names.
I hope most of them has been already fixed with
https://bugzilla.redhat.com/show_bug.cgi?id=682334
We
On Sun, 27.01.13 01:06, Oron Peled (o...@actcom.co.il) wrote:
On Wednesday 23 January 2013 23:49:48 Kay Sievers wrote:
...
We had no better idea really, than to copy the successful model we do
for disks (and other subsystems) with /dev/disk/by-*/ symlinks. It was
a well-known scheme, but
On Jan 25, 2013 3:45 PM, Marcela Mašláňová mmasl...@redhat.com wrote:
On 01/25/2013 12:17 AM, Adam Williamson wrote:
On Thu, 2013-01-24 at 23:03 +, Jóhann B. Guðmundsson wrote:
It's best to rip the bandage of this in one release.
The churn from this should have been more or less
On Wednesday 23 January 2013 23:49:48 Kay Sievers wrote:
...
We had no better idea really, than to copy the successful model we do
for disks (and other subsystems) with /dev/disk/by-*/ symlinks. It was
a well-known scheme, but it was certainly not know for network devices
so far. So we picked
On Thu, Jan 24, 2013 at 11:32:31PM +0100, Lennart Poettering wrote:
One problem with biosdevname is that it uses different naming schemes in
the same namespace. For us, predictability means that by looking at the
lspci or DMI information of your card you can deterministically figure
out how
On 01/25/2013 12:17 AM, Adam Williamson wrote:
On Thu, 2013-01-24 at 23:03 +, Jóhann B. Guðmundsson wrote:
It's best to rip the bandage of this in one release.
The churn from this should have been more or less covered when we
implement biosdevname so the fallout from this change should be
On Thu, Jan 24, 2013 at 12:28:59AM +0100, Lennart Poettering wrote:
That inventing your own numbering is a problem manifests itself in bugs
like this:
https://bugzilla.redhat.com/show_bug.cgi?id=782145#c21
Okay, I can see that. Still, I wish there were a greater attempt to maintain
similar
On 01/23/2013 01:54 PM, Bill Nottingham wrote:
This code has the benefit of:
- covering more device types (not just BIOSes with type 9 type 41)
- not attempting to do heuristics that name devices via enumeration
However, it does have the large disadvantage of changing the namespace used.
On 01/24/2013 03:17 PM, John Reiser wrote:
On 01/23/2013 01:54 PM, Bill Nottingham wrote:
This code has the benefit of:
- covering more device types (not just BIOSes with type 9 type 41)
- not attempting to do heuristics that name devices via enumeration
However, it does have the large
On 01/24/2013 04:17 PM, John Reiser wrote:
Another cause for concern by users is the maintenance record of systemd:
https://bugzilla.redhat.com/show_bug.cgi?id=841822
pungi can't create installable media with F17 + updates
For about five months from July through December 2012
The Bodhi
On Thu, 24.01.13 07:17, John Reiser (jrei...@bitwagon.com) wrote:
On 01/23/2013 01:54 PM, Bill Nottingham wrote:
This code has the benefit of:
- covering more device types (not just BIOSes with type 9 type 41)
- not attempting to do heuristics that name devices via enumeration
Orion Poplawski (or...@cora.nwra.com) said:
I'm not trying to disparage this work, it seems reasonable (although
I've been bitten by a lot of crappy software assuming network
devices are named eth#, but it's able to be turned off, so meh).
We went through most of the things we shipped back
Matthew Miller (mat...@fedoraproject.org) said:
But I guess we simply have a different definition of a user here. Your
definition is probably closer to what the page calls admins, which is
covered by the next lines in the feature page, which you didn't paste:
Right. For Fedora,
On Thu, Jan 24, 2013 at 8:57 PM, Bill Nottingham nott...@redhat.com wrote:
Matthew Miller (mat...@fedoraproject.org) said:
But I guess we simply have a different definition of a user here. Your
definition is probably closer to what the page calls admins, which is
covered by the next lines
On Thu, Jan 24, 2013 at 8:57 PM, Bill Nottingham nott...@redhat.com wrote:
Matthew Miller (mat...@fedoraproject.org) said:
But I guess we simply have a different definition of a user here. Your
definition is probably closer to what the page calls admins, which is
covered by the next lines
On Wed, Jan 23, 2013 at 8:59 PM, Jaroslav Reznik jrez...@redhat.com wrote:
= Features/SystemdPredictableNetworkInterfaceNames =
https://fedoraproject.org/wiki/Features/SystemdPredictableNetworkInterfaceNames
Feature owner(s): Kay Sievers kay at redhat dot com
The udevd service has a long
On Thu, 24.01.13 22:28, Miloslav Trmač (m...@volny.cz) wrote:
What concerns would people have with this naming? Off the top of my head:
- wwan devices aren't always discoverable (they can show up as ethernet)
- devices that biosdevname considers emX via enumeration/guessing would
now
On Thu, 24.01.13 08:48, Matthew Miller (mat...@fedoraproject.org) wrote:
As biosdevname is installed by default ... most administrators won't
see this either.
If the new scheme really is better, we should suck it up and make the whole
change. It'd be better to do what we can to make
On Thu, 24.01.13 14:57, Bill Nottingham (nott...@redhat.com) wrote:
Matthew Miller (mat...@fedoraproject.org) said:
But I guess we simply have a different definition of a user here. Your
definition is probably closer to what the page calls admins, which is
covered by the next lines in
On Thu, 2013-01-24 at 14:57 -0500, Bill Nottingham wrote:
Matthew Miller (mat...@fedoraproject.org) said:
But I guess we simply have a different definition of a user here. Your
definition is probably closer to what the page calls admins, which is
covered by the next lines in the feature
Miloslav Trmač (m...@volny.cz) said:
On Wed, Jan 23, 2013 at 8:59 PM, Jaroslav Reznik jrez...@redhat.com wrote:
= Features/SystemdPredictableNetworkInterfaceNames =
https://fedoraproject.org/wiki/Features/SystemdPredictableNetworkInterfaceNames
Feature owner(s): Kay Sievers kay at
On 01/24/2013 10:43 PM, Adam Williamson wrote:
On Thu, 2013-01-24 at 14:57 -0500, Bill Nottingham wrote:
Matthew Miller (mat...@fedoraproject.org) said:
But I guess we simply have a different definition of a user here. Your
definition is probably closer to what the page calls admins, which is
On Thu, 2013-01-24 at 23:03 +, Jóhann B. Guðmundsson wrote:
It's best to rip the bandage of this in one release.
The churn from this should have been more or less covered when we
implement biosdevname so the fallout from this change should be minimal
if any...
I see the 's' word in
On Wed, Jan 23, 2013 at 07:59:07PM +, Jaroslav Reznik wrote:
The udevd service has a long history of providing predicatable names for
block devices and others. For Fedora 19 we'd like to provide the same for
network interfaces, following a similar naming scheme, but only as
fallback if not
On 01/23/2013 12:26 PM, Matthew Miller wrote:
Also, I strongly question this line in the Feature page:
Users generally won't see this, as interface names are not exposed in
high-level UIs.
This is simply not true for many values of the word user
I agree with Matthew that ordinary
Matthew Miller (mat...@fedoraproject.org) said:
On Wed, Jan 23, 2013 at 07:59:07PM +, Jaroslav Reznik wrote:
The udevd service has a long history of providing predicatable names for
block devices and others. For Fedora 19 we'd like to provide the same for
network interfaces, following
On 01/23/2013 09:08 PM, John Reiser wrote:
On 01/23/2013 12:26 PM, Matthew Miller wrote:
Also, I strongly question this line in the Feature page:
Users generally won't see this, as interface names are not exposed in
high-level UIs.
This is simply not true for many values of the word
On Wed, Jan 23, 2013 at 10:54 PM, Bill Nottingham nott...@redhat.com wrote:
Matthew Miller (mat...@fedoraproject.org) said:
On Wed, Jan 23, 2013 at 07:59:07PM +, Jaroslav Reznik wrote:
The udevd service has a long history of providing predicatable names for
block devices and others. For
On Wed, 23.01.13 15:26, Matthew Miller (mat...@fedoraproject.org) wrote:
On Wed, Jan 23, 2013 at 07:59:07PM +, Jaroslav Reznik wrote:
The udevd service has a long history of providing predicatable names for
block devices and others. For Fedora 19 we'd like to provide the same for
Hi
On Wed, Jan 23, 2013 at 6:28 PM, Lennart Poettering wrote:
As biosdevname is installed by default ... most administrators won't
see this either.
Why doesn;t the proposal request that biosdevname not be installed by
default anymore?
Rahul
--
devel mailing list
On Wed, 23.01.13 16:54, Bill Nottingham (nott...@redhat.com) wrote:
However, it does have the large disadvantage of changing the namespace used.
Yes, this is definitely a disadvantage. Which is why we carefully made
sure that the new scheme doesn't affect systems which already rely on
the
On 01/23/2013 02:49 PM, Kay Sievers wrote:
Just looking at 'lspci' will in most
cases tell you what the name of the network interface will be.
This is not true for my machines, which I built using main boards
from ASUS, MSI, etc. The port numbers listed by 'lspci'
On Wed, 23.01.13 16:07, John Reiser (jrei...@bitwagon.com) wrote:
On 01/23/2013 02:49 PM, Kay Sievers wrote:
Just looking at 'lspci' will in most
cases tell you what the name of the network interface will be.
This is not true for my machines, which I built using
On Thu, Jan 24, 2013 at 1:07 AM, John Reiser jrei...@bitwagon.com wrote:
On 01/23/2013 02:49 PM, Kay Sievers wrote:
Just looking at 'lspci' will in most
cases tell you what the name of the network interface will be.
This is not true for my machines, which I built
On 01/23/2013 05:29 PM, Kay Sievers wrote:
What udev does here is the only sensible thing to do, if there is no
authoritative information from the firmware about that, we don't make
assumptions, we use the reasonable stable PCI geography. Guessing
around which might the human slot number should
On Thu, Jan 24, 2013 at 3:46 AM, Orion Poplawski or...@cora.nwra.com wrote:
On 01/23/2013 05:29 PM, Kay Sievers wrote:
What udev does here is the only sensible thing to do, if there is no
authoritative information from the firmware about that, we don't make
assumptions, we use the reasonable
84 matches
Mail list logo
