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: Is there any docs or design guides for adding hotplugablity to
Date: Tue, 02 Jul 2002 02:23:10 +0000	[thread overview]
Message-ID: <marc-linux-hotplug-102557694909422@msgid-missing> (raw)
In-Reply-To: <marc-linux-hotplug-102555728227620@msgid-missing>

Mark Atwood wrote:
> Other than just reading the source, of course.

Start there, and then ask questions.  The docs that exist
are on the http://linux-hotplug.sf.net website, and in the
source code for the various subsystems that do hotplugging.

Inside the kernel, one basically invokes the program identified
by /proc/sys/kernel/hotplug, using a simple convention (only
argv[1] is standard) with call_usermodehelper() to report those
events.  Normally one wants the events to be reported by some
subsystem/framework code, rather than individual drivers, since
it's a lose to expect every driver be changed.


> I'm working on a Linux appliance, and I feel that using hotplug events
> to signal things like moving in range of an 802.11 access point,
> getting carrier on an ethernet port, and someone plugging a cable into
> the serial port, would make a lot of stuff much much easier.
> 
> I suspect that a lot of this would be useful out in the "regular
> linux" world as well. Especially the ethernet carrier detect. (Windows
> can do it, and will invoke DHCP when you plug in an ethernet cable, it
> would be nice if Linux can do the same.)

I agree that carrier detect would be good to report through hotplug,
since that's actually the relevant event.  Since the network drivers
don't actually agree on an initialization model (some register
before going "up", others don't -- see the special casing in
the /etc/hotplug/net.agent script for a start), some of the basic
issues there relate to the networking stack.

Last I looked, the network stack didn't actually treat carrier
detect as an interesting event, which makes such changes be unduly
complex.  If you're interested in updating the 2.5 stack to do
such things, I'd suggest discussing this on the netdev list and
shipping code before the planned feature freeze on Hallowe'en... :)

- Dave







-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
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

  reply	other threads:[~2002-07-02  2:23 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-07-01 21:00 Is there any docs or design guides for adding hotplugablity to drivers? Mark Atwood
2002-07-02  2:23 ` David Brownell [this message]
2002-07-02  2:32 ` Chris Hanson
2002-07-02  3:37 ` Brad Hards
2002-07-02  4:52 ` Greg KH

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-102557694909422@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).