linux-hotplug.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Brownell <david-b@pacbell.net>
To: linux-hotplug@vger.kernel.org
Subject: Re: Network hotplug semantics
Date: Fri, 09 Feb 2001 00:28:32 +0000	[thread overview]
Message-ID: <marc-linux-hotplug-98168013332206@msgid-missing> (raw)
In-Reply-To: <marc-linux-hotplug-98161573514987@msgid-missing>

Today, hotplug events basically involve namespace update activities:
for network hotplug events it's just "register" or "unregister".  No
event corresponds to "plugged".

However, I think in general it'd be good to assume that network
interfaces may not be "ready for use" right away.  For example,
there's no sense in even trying to figure out how to route (much
less start advertising a route!) until the link is really usable.  And
when the interface isn't statically configured, the same issue is true
for DHCP setup even earlier than that.

There are two network API calls that seem like they're intended
to be used in such cases:  netif_device_attach(), and its sibling
netif_device_detach() in linux/netdevice.h ... but they seem to
just be queue block/unblock primitives, despite what their names
imply.  The way 3c59x.c and xirc2ps_cs.c use them seems to
relate to handling hotplug and suspend/resume events.

- Dave


----- Original Message ----- 
From: "Oliver Neukum" <Oliver.Neukum@lrz.uni-muenchen.de>
To: "Brad Hards" <bhards@bigpond.net.au>; <linux-hotplug-devel@lists.sourceforge.net>
Sent: Thursday, February 08, 2001 12:32 AM
Subject: Re: Network hotplug semantics


> On Donnerstag,  8. Februar 2001 08:03, Brad Hards wrote:
> > Situation: USB ethernet adapter (in my case, a KLSI one).
> >
> > Should the interface (e.g. ethX) be signalled when the device is plugged
> > in to the USB port, or when the electrical connection of the 10BaseT
> > wire is made? What counts as "plugged" in this case?
> 
> Quite a lot of ethernet controllers can't tell you whether a wire is 
> connected. For other things like wireless networking the destinction is hard
> to make. Thus to keep things unified, as soon as the card is up.
> 
> Regards
> Oliver
> 
> _______________________________________________
> Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
> Linux-hotplug-devel@lists.sourceforge.net
> http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel


_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

  parent reply	other threads:[~2001-02-09  0:28 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-02-08  7:02 Network hotplug semantics Matthew Dharm
2001-02-08  7:03 ` Brad Hards
2001-02-08  8:32 ` Oliver Neukum
2001-02-09  0:28 ` David Brownell [this message]
2001-02-09  1:27 ` Andrew Morton
2001-02-10  3:46 ` Brad Hards

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=marc-linux-hotplug-98168013332206@msgid-missing \
    --to=david-b@pacbell.net \
    --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).