From: Kay Sievers <kay.sievers@vrfy.org>
To: linux-hotplug@vger.kernel.org
Subject: Re: how does udev rename an interface?
Date: Sun, 26 Dec 2004 13:57:16 +0000 [thread overview]
Message-ID: <1104069436.16548.28.camel@localhost.localdomain> (raw)
In-Reply-To: <20041226112849.GA8995@fishbowl>
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
prev parent reply other threads:[~2004-12-26 13:57 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-12-26 11:28 how does udev rename an interface? martin f krafft
2004-12-26 12:33 ` Kay Sievers
2004-12-26 13:30 ` martin f krafft
2004-12-26 13:57 ` Kay Sievers [this message]
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=1104069436.16548.28.camel@localhost.localdomain \
--to=kay.sievers@vrfy.org \
--cc=linux-hotplug@vger.kernel.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;
as well as URLs for NNTP newsgroup(s).