On 2013-04-02, Neil Bothwick <n...@digimed.co.uk> wrote:
> On Tue, 2 Apr 2013 20:31:10 +0000 (UTC), Grant Edwards wrote:
>
>> In Flameyes blog, he showed an example of using udev rules pretty much
>> identical to the ones I already had, so I couldn't figure out what was
>> different (other than the default interface names, which still aren't
>> really predictable).
>
> They are totally predictable,

As long as you know the PCI bus IDs of the slots, which board is
plugged into which slot, the PCI bus IDs of the USB controllers, and
which USB ports are connected to which controllers, and so on.  For
most of us that equates to "not predictable".  :)

The one thing (AFAICT) that does sort of make them what I would call
"predictable" is the support for BIOS labels for ports.  I've never
actually seen a machine that supported that.

> since the names are specified in the rules, so you can predict what
> the interface will be called,

In _theory_ you can, but you need to gather a lot of very low-level
information first.  In practice, I bet nobody does that -- they just
boot up the kernel and see what they get.

> it's what the rules file says it will be called. However, the
> important issue is persistence, whatever name an interface has is the
> name it will always have.

Until you move it to a different USB port or PCI slot.  Names still
aren't persistent (or, in practical terms, predictable), they're just
based on a different parameter than they used to be.  For some people
the new 'prameter' is apparently more useful -- so I guess it's an
improvement.

> The rules renaming within the kernel namespace, eth, wlan etc, could
> not guarantee that because of race conditions, and the so-called
> persistent names from the new udev still cannot do the same for
> devices that can be physically moved (mainly USB).
>
> The simplest solution is to do what the news item suggests, rename
> the persistent-net rules file

Why does the file need to be renamed?

> and rename the interfaces within it to not clash with the kernel.

So the kernel is still using the names eth[0-n]?  And there's a race
condition if I use the names eth[0-n] in my rules?  Same as before?

> That's all you need to worry about when going from 197 to 200,
> upgrading from earlier versions means you should act on the parts
> about DEVTMPFS and runlevel files.

-- 
Grant Edwards               grant.b.edwards        Yow! My life is a patio
                                  at               of fun!
                              gmail.com            


Reply via email to