From: Kay Sievers <kay.sievers@vrfy.org>
To: linux-hotplug@vger.kernel.org
Subject: Re: Hotplugging ethernet cables.
Date: Tue, 04 Jan 2005 18:38:36 +0000 [thread overview]
Message-ID: <1104863916.5258.32.camel@localhost.localdomain> (raw)
In-Reply-To: <41D74A49.2060607@are-b.org>
On Tue, 2005-01-04 at 11:44 -0600, Linas Vepstas wrote:
> A naive question re ethernet hotplug: what if its iSCSI?
>
> On Sun, Jan 02, 2005 at 01:43:32AM +0100, Kay Sievers was heard to remark:
> > On Sun, 2005-01-02 at 02:11 +0100, oliver wrote:
> > > They mention ifplugd and even though this seems to work reasonably, I
> > > was wondering why hotplugging doesn't support ethernet hotplugging
> > > nativly?
> >
> > Hotplug supports device add and remove, not state changes of hardware.
> >
> > > As I understand it the hotplugging daemon responds to events
> > > created by several devices, where the ifplugd polls and the device.
> >
> > There is no such daemon involved in the hotplug handling. Hotplug is
> > driven by more or less stateless scripts invoked by the kernel.
> >
> > The network link state changes can be received on a netlink socket from
> > the kernel. These events are not hotplug events and don't really fit
> > into the model of linux hotplug.
>
>
> I can imagine a scenario where Linux has mounted a filesystem that
> is sitting on an iSCSI disk device. Thus, in many respects, this is
> analogous to a USB disk being plugged and unplugged. I also presume
> that iSCSI devices need not be just disks, but could be "anything",
> thus making the situation even more analogous to USB.
Sure, it's similar in some aspects, but linux-hotplug is only a device
"add" or "remove" notification. Every event corresponds to a created or
removed directory in /sys. There is no such thing for a network link.
If you add/remove the network device you get hotplug events. You don't
get hotplug events if you press a button of an USB device, which is very
similar to the network link state change. :)
Some networking applications produce a very high event traffic for state
changes - like the zebra routing daemon, this is definitely not possible
to do with the event-by-forked-helper-application-hotplug system. They
use the netlink socket for good reason. What do you think is the problem
to get network layer events over netlink? It works nicely this way for a
long time.
For a application level feature rich example, you may look how HAL is
collecting all available kernel events and offers a unified interface to
applications to subscribe to these events:
http://cvs.freedesktop.org/*checkout*/hal/hal/doc/spec/hal-spec.html?rev=1.36.2.5
> I'm also curious about plans for things like infiniband fabrics,
> which might be plugged/unplugged in various ways, which the OS might
> want to know about. Again, this seems clearly analogous to USB fabrics
Never seen such a thing. :)
Kay
-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
_______________________________________________
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
next prev parent reply other threads:[~2005-01-04 18:38 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-01-02 0:12 Hotplugging ethernet cables oliver
2005-01-02 0:43 ` Kay Sievers
2005-01-04 17:44 ` Linas Vepstas
2005-01-04 18:38 ` Kay Sievers [this message]
2005-01-05 11:29 ` Oliver Schinagl
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=1104863916.5258.32.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.