public inbox for gentoo-user@lists.gentoo.org
 help / color / mirror / Atom feed
From: Samuli Suominen <ssuominen@gentoo.org>
To: gentoo-user@lists.gentoo.org
Subject: Re: [gentoo-user] Re: udev (viable) alternatives ?
Date: Fri, 26 Sep 2014 12:04:47 +0300	[thread overview]
Message-ID: <54252C2F.1030901@gentoo.org> (raw)
In-Reply-To: <54252834.4030305@gentoo.org>


On 26/09/14 11:47, Samuli Suominen wrote:
> On 26/09/14 11:22, Canek Peláez Valdés wrote:
>> On Fri, Sep 26, 2014 at 3:07 AM, Neil Bothwick <neil@digimed.co.uk> wrote:
>>> On Fri, 26 Sep 2014 05:27:15 +0200, Alan McKinnon wrote:
>>>
>>>>>   I buy machines with one ethernet interface.  What I find
>>>>> particularly annoying is this doublespeak about calling it
>>>>> "predictable".  Before the change, it was predicatbly "eth0".  Now,
>>>>> it's different on every different model.
>>>> It's not doublespeak, the interfaces are named exactly according to
>>>> where they are on the PCI bus. If you had two interfaces, they show up
>>>> to the kernel in random order by time and sometimes eth0/eth1 are nto
>>>> the same they were before the reboot.
>>> That may be true for PCI devices but not for USB ones. If you unplug a
>>> USB device and plug it back into the same port, it will get a different
>>> device number. The naming is more predictable, but it's not there yet.
>> That doesn't sound right. If unplugging a USB net device and plugging
>> it again *in the same port* results in a different device *name*, then
>> it is a bug and should be reported; the description of the algorithm
>> in [1] sounds like it should get always the same name for the same
>> port, unless I'm misunderstanding something.
>>
>> Regards.
>>
>> [1] http://cgit.freedesktop.org/systemd/systemd/tree/src/udev/udev-builtin-net_id.c#n51
> I've seen this happening once on a cheap laptop with a stripped down
> BIOS I can't
> even recall brand for, it had a kludge in the BIOS settings for
> hotplugging, turning
> it off, allowed the port to remain same, turning it on, some machine
> specific code
> gets executed and the kernel interprets the same port as different port
>
> Bad hardware, bad hardware settings, maybe missing exception for that
> particular
> hardware type in the code that determines the name... I'm not sure, I
> don't have
> the machine anymore
>
> - Samuli
>

Later kernels *can mark interfaces predictable in a new form of
metadata*, and udev >= 209 can
pick that information up, and then it won't do anykind of userspace
renaming on it, since kernel
has declared the interface name to be steady...predictable...always
same, so I hope
we are moving towards kernel assigning predictable names for all drivers
and we can get rid of
the userspace renaming of interfaces all together at some point
I really believe this is a task for the kernel to provide predictable
names, and all this userspace
renaming is just a bandage we can hopefully soon rip off

- Samuli


  reply	other threads:[~2014-09-26  9:05 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-25 15:25 [gentoo-user] udev (viable) alternatives ? James
2014-09-25 17:47 ` Dale
2014-09-25 18:17 ` Samuli Suominen
2014-09-25 19:03   ` [gentoo-user] " James
2014-09-25 19:32     ` Dale
2014-09-26  0:23     ` Walter Dnes
2014-09-26  3:27       ` Alan McKinnon
2014-09-26  8:07         ` Neil Bothwick
2014-09-26  8:22           ` Canek Peláez Valdés
2014-09-26  8:46             ` Neil Bothwick
2014-09-26  8:47             ` Samuli Suominen
2014-09-26  9:04               ` Samuli Suominen [this message]
2014-09-26 16:47                 ` David W Noon
2014-09-27  2:06                   ` Samuli Suominen
2014-09-26  5:04     ` Samuli Suominen
2014-11-10 11:04       ` Tanstaafl
2014-11-10 12:30         ` Rich Freeman
2014-11-10 13:23           ` Tanstaafl
2014-11-10 14:23             ` Rich Freeman
2014-11-10 15:48         ` Samuli Suominen
2014-11-10 16:01           ` Tanstaafl
2014-11-11  5:20           ` Walter Dnes
2014-11-11  5:33             ` Samuli Suominen
2014-11-11  5:35             ` Canek Peláez Valdés
2014-11-11 12:18             ` Rich Freeman
2014-11-13 17:08               ` Walter Dnes
2014-11-17 10:27                 ` Tom H

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=54252C2F.1030901@gentoo.org \
    --to=ssuominen@gentoo.org \
    --cc=gentoo-user@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox