doraproject.org
>> Subject: Re: Proposed F19 Feature: systemd/udev Predictable Network
>> Interface Names
>>
>> On 03/04/2013 04:01 PM, Matt Domsch wrote:
>> > drivers/net/ethernet/sfc/siena.c: efx->net_dev->dev_id =
>> EFX_OWORD_FIELD(reg, FRF_CZ_CS_PO
> -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: system
On Tue, Mar 5, 2013 at 5:52 PM, Michal Schmidt 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 multi-po
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, Mar 4, 2013 at 6:01 PM, Andy Gospodarek 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 =
>> > > EFX_OWORD_FIELD(reg,
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 bec
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 consu
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...@d
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, Bil
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
> > 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.
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 c
Kay Sievers (k...@vrfy.org) said:
> On Mon, Feb 25, 2013 at 6:02 PM, Andy Gospodarek 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. biosd
On 02/28/2013 06:55 AM, Kay Sievers wrote:
> On Mon, Feb 25, 2013 at 6:02 PM, Andy Gospodarek 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. bio
On Mon, Feb 25, 2013 at 6:02 PM, Andy Gospodarek 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 such a time
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 per-sy
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/M
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 don
On Tue, Feb 12, 2013 at 4:44 PM, Matt Domsch 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 leaves the kernel
On Thu, Feb 07, 2013 at 09:22:40PM -0600, Kay Sievers wrote:
> On Thu, Feb 7, 2013 at 7:12 AM, Matt Domsch 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
On Thu, Feb 7, 2013 at 7:12 AM, Matt Domsch 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
>distro-wide per-ve
On Thu, Feb 7, 2013 at 11:36 PM, Glen Turner wrote:
> On 29/01/13 05:32, Lennart Poettering wrote:
>
>> We figured in this it's better to just stick to a single name for each
>> iface, pick a good default scheme for it, and support alternative
>> schemes.
>
> The whole point of biosdevname was to
On Thu, Feb 7, 2013 at 12:07 PM, Bradley Baetz wrote:
> On 07/02/13 00:33, Michal Schmidt wrote:
>>
>> 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
>>>
On Thu, Feb 07, 2013 at 10:07:59PM +1100, Bradley Baetz wrote:
> What happens with USB network devices that are plugged into
> different slots? Currently my iPhone shows up as eth1, but using the
> above, depending on which of two adjacent ports I happen to plug it
> into, I get:
>
> $ udevadm inf
On 29/01/13 05:32, Lennart Poettering wrote:
> We figured in this it's better to just stick to a single name for each
> iface, pick a good default scheme for it, and support alternative
> schemes.
The whole point of biosdevname was to move from a ennumeration-centric
view or a bus-centric view of
On 07/02/13 00:33, Michal Schmidt wrote:
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 applie
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 ma
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:
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 you
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 techn
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 reasons. There is no reliable information about
that on the system,
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 und
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.
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 w
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 d
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% o
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
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
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 c
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 wan
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 na
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 added
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 added confirmation that any attempt to fig
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
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:
https://bugzi
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á
> 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 th
On Tue, Jan 29, 2013 at 6:35 PM, "Jóhann B. Guðmundsson"
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 in the project
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
On 01/29/2013 05:20 PM, Miloslav Trmač wrote:
On Fri, Jan 25, 2013 at 4:25 PM, Marcela Mašláňová 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 s
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
On Fri, Jan 25, 2013 at 4:25 PM, Marcela Mašláňová 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 c
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 sch
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
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, w
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
> https://bugzilla.redhat.com/
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
devel@lists.fedoraproj
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 pi
On Jan 25, 2013 3:45 PM, "Marcela Mašláňová" 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 cover
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 b
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 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' wor
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
Miloslav Trmač (m...@volny.cz) said:
> On Wed, Jan 23, 2013 at 8:59 PM, Jaroslav Reznik wrote:
> > = Features/SystemdPredictableNetworkInterfaceNames =
> > https://fedoraproject.org/wiki/Features/SystemdPredictableNetworkInterfaceNames
> >
> > Feature owner(s): Kay Sievers
> >
> > The udevd ser
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
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 nex
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
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
>
On Wed, Jan 23, 2013 at 8:59 PM, Jaroslav Reznik wrote:
> = Features/SystemdPredictableNetworkInterfaceNames =
> https://fedoraproject.org/wiki/Features/SystemdPredictableNetworkInterfaceNames
>
> Feature owner(s): Kay Sievers
>
> The udevd service has a long history of providing predicatable na
On Thu, Jan 24, 2013 at 8:57 PM, 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 f
On Thu, Jan 24, 2013 at 8:57 PM, 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 f
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,
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
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
>
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 p
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 disad
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 us
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 n
On Thu, Jan 24, 2013 at 3:46 AM, Orion Poplawski 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 stable PCI
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 1:07 AM, John Reiser 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 main boards
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
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' (th
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 stabl
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
devel@lists.fedora
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
> >
On Wed, Jan 23, 2013 at 10:54 PM, Bill Nottingham 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 Fedora 19
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 "
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, foll
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 or
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
= Features/SystemdPredictableNetworkInterfaceNames =
https://fedoraproject.org/wiki/Features/SystemdPredictableNetworkInterfaceNames
Feature owner(s): Kay Sievers
The udevd service has a long history of providing predicatable names for block
devices and others. For Fedora 19 we'd like to prov
91 matches
Mail list logo
