how does udev rename an interface?

how does udev rename an interface?

[martin f krafft]

[-- Attachment #1: Type: text/plain, Size: 1539 bytes --]

udev has the ability to rename network interfaces. At least on my
system, udevsend is called from /etc/hotplug.d/default. A network
device usually triggers two hotplug events, the first for the
device, and the second for the network interface. Therefore, udev
runs twice, but network interface renaming only makes sense during
the second invocation, since it only applies to network interfaces.

I have two questions about how udev handles this:

  - /etc/hotplug.d/net/*.hotplug are run before udevsend is called
    from /etc/hotplug.d/default. Thus, if a tool such as ifplugd
    already configures the network interface with
    /etc/hotplug.d/net, udev effectively cannot change the
    interface name because the interface is in use.

  - even if udev changes the interface name, how does it communicate
    the new name to net.agent and all the other hook scripts? The
    interface name is stored in $INTERFACE in the environment of the
    hotplug process, and udev cannot change that environment (or can
    it?).

How does udev deal with this?

Thanks,

-- 
martin;              (greetings from the heart of the sun.)
  \____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
 
invalid/expired pgp subkeys? use subkeys.pgp.net as keyserver!
spamtraps: madduck.bogus@madduck.net
 
if it's there, and you can see it, it's real.
if it's not there, and you can see it, it's virtual.
if it's there, and you can't see it, it's transparent.
if it's not there, and you can't see it, you erased it.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: how does udev rename an interface?

[Kay Sievers]

On Sun, 2004-12-26 at 12:28 +0100, martin f krafft wrote:
> udev has the ability to rename network interfaces. At least on my
> system, udevsend is called from /etc/hotplug.d/default. A network
> device usually triggers two hotplug events, the first for the
> device, and the second for the network interface. Therefore, udev
> runs twice, but network interface renaming only makes sense during
> the second invocation, since it only applies to network interfaces.
> 
> I have two questions about how udev handles this:
> 
>   - /etc/hotplug.d/net/*.hotplug are run before udevsend is called
>     from /etc/hotplug.d/default. Thus, if a tool such as ifplugd
>     already configures the network interface with
>     /etc/hotplug.d/net, udev effectively cannot change the
>     interface name because the interface is in use.

Right, if something brings up the netif earlier, udev can't do anything.

>   - even if udev changes the interface name, how does it communicate
>     the new name to net.agent and all the other hook scripts?The
>     interface name is stored in $INTERFACE in the environment of the
>     hotplug process, and udev cannot change that environment (or can
>     it?).

On a successful rename, udev calls the /etc/dev.d/net/hotplug.dev
script, which calls the /etc/hotplug.d/default/default.hotplug again
with the corrected environment.

> How does udev deal with this?

If /sbin/udevsend is used as the hotplug helper and udevd manages the
complete hotplug event, only one correct hotplug netif call is visible
to the hotplug scripts. The one for the old name will be "converted" to
carry the new name and no second event needs to be faked.

Kay



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: how does udev rename an interface?

[martin f krafft]

[-- Attachment #1: Type: text/plain, Size: 1865 bytes --]

also sprach Kay Sievers <kay.sievers@vrfy.org> [2004.12.26.1333 +0100]:
> Right, if something brings up the netif earlier, udev can't do
> anything.

Therefore, ifplugd should really not be called in hotplug.d, but
through net.agent, huh?

> On a successful rename, udev calls the /etc/dev.d/net/hotplug.dev
> script, which calls the /etc/hotplug.d/default/default.hotplug
> again with the corrected environment.

From what I understand, udevsend is only one hook that is run, and
hotplug simply runs the next on competion. udevsend must therefore
somehow tell hotplug to abort the processing of remaining hooks
before invoking the /dev/dev.d script again. How does it do that?
With a non-zero exit code?

I am sorry for asking these questions... I am currently on an
ass-slow machine in my parents' house, and it would take me an hour
to figure this out... mutt takes 25 seconds to spawn. :/

> If /sbin/udevsend is used as the hotplug helper and udevd manages
> the complete hotplug event, only one correct hotplug netif call is
> visible to the hotplug scripts. The one for the old name will be
> "converted" to carry the new name and no second event needs to be
> faked.

Right, /etc/dev.d/net/hotplug.dev is the secret. It executes:

  exec /etc/hotplug.d/default/default.hotplug net

if the interface was renamed. If I can figure out how it stops the
hotplug instance that invoked udev from running further hooks, we
got a winner.

Cheers,

-- 
martin;              (greetings from the heart of the sun.)
  \____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
 
invalid/expired pgp subkeys? use subkeys.pgp.net as keyserver!
spamtraps: madduck.bogus@madduck.net
 
man muss noch chaos in sich haben
um einen tanzenden stern zu gebähren.
                                                -- friedrich nietzsche

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: how does udev rename an interface?

[Kay Sievers]

On Sun, 2004-12-26 at 14:30 +0100, martin f krafft wrote:
> also sprach Kay Sievers <kay.sievers@vrfy.org> [2004.12.26.1333 +0100]:
> > Right, if something brings up the netif earlier, udev can't do
> > anything.
> 
> Therefore, ifplugd should really not be called in hotplug.d, but
> through net.agent, huh?
> 
> > On a successful rename, udev calls the /etc/dev.d/net/hotplug.dev
> > script, which calls the /etc/hotplug.d/default/default.hotplug
> > again with the corrected environment.
> 
> From what I understand, udevsend is only one hook that is run, and
> hotplug simply runs the next on competion. udevsend must therefore
> somehow tell hotplug to abort the processing of remaining hooks
> before invoking the /dev/dev.d script again. How does it do that?
> With a non-zero exit code?

No, the DEVPATH in sysfs disappeared after the rename, the scripts will
just need to exit.

> > If /sbin/udevsend is used as the hotplug helper and udevd manages
> > the complete hotplug event, only one correct hotplug netif call is
> > visible to the hotplug scripts. The one for the old name will be
> > "converted" to carry the new name and no second event needs to be
> > faked.
> 
> Right, /etc/dev.d/net/hotplug.dev is the secret. It executes:
> 
>   exec /etc/hotplug.d/default/default.hotplug net
> 
> if the interface was renamed. If I can figure out how it stops the
> hotplug instance that invoked udev from running further hooks, we
> got a winner.

It's not stopped. All hotplug users _must_ be aware that the device is
gone in the meantime. This may happen in other situations too.

Kay



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel