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: /sbin/hotplug invocation for USB devices in 2.5.40
Date: Wed, 09 Oct 2002 15:15:27 +0000	[thread overview]
Message-ID: <marc-linux-hotplug-103417677631539@msgid-missing> (raw)
In-Reply-To: <marc-linux-hotplug-103406277101783@msgid-missing>


>>But USBFS lets you interact with the device, and every user mode driver
>>(or configuration tool) relies on that.  Many of them hook up through
>>hotplug.  KFS doesn't; which is why the agents will continue to need
>>the USBFS path.
> 
> 
> I want to remove the fact that usbfs is being used by the hotplug
> scripts.  

So far as the "load the driver" part of those scripts, I agree it
shouldn't be needed.  But hotplug agents do more than just loading
drivers


 > 	I don't care about any userspace drivers or configuration
> scripts, they can determine the usbfs location from the driverfs/kfs
> device already.

Not the last time I looked they couldn't !!

But even if they could, then the hotplug scripts would want to set
the usbfs DEVICE= parameter before calling setup/config scripts,
which often call userspace drivers.   Intentionally breaking such
third party software is not somehing I'm keen on.


>>There's also the "coldplug" situation.  KFS _could_ remember which
>>devices didn't have hotplug events issued (a device state flag) and
>>rescan its tree to issue them, after the kernel's come up enough that
>>/sbin/hotplug can safely be called.  Only solving that issue lets us
>>completely get rid of "usbmodules".
> 
> 
> No, kfs isn't going to do a "coldplug" store and replay thing.

I've yet to hear another scheme that would solve the whole
"coldplug" problem, though ... there always seems to be some
case (like the right driver being missing from initramfs) that
is more naturally handled just by deferring the event report.

Not store/replay -- one bit per device, and ftw() code that
could likely be removed after the system's running.


> What is going to happen is /sbin/hotplug will be present early in the
> boot due to initramfs, so the proper modules will already be loaded.  If
> userspace wants to walk the driverfs/kfs tree when init starts up,
> that's up to it.
> 
> And yes, I really want to get rid of usbmodules too :)

I've heard of this initramfs scheme, but it's almost Hallowe'en ...
but maybe this falls under the "scarey costume" exception!  :)

- 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

  parent reply	other threads:[~2002-10-09 15:15 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-10-08  7:32 /sbin/hotplug invocation for USB devices in 2.5.40 Greg KH
2002-10-08 17:02 ` David Brownell
2002-10-08 17:49 ` Patrick Mochel
2002-10-08 17:55 ` Oliver Neukum
2002-10-08 18:14 ` David Brownell
2002-10-08 18:18 ` Oliver Neukum
2002-10-08 18:18 ` Greg KH
2002-10-08 18:25 ` Greg KH
2002-10-08 21:00 ` David Brownell
2002-10-08 21:17 ` Greg KH
2002-10-08 21:18 ` David Brownell
2002-10-08 21:28 ` David Brownell
2002-10-08 21:39 ` Greg KH
2002-10-09 15:15 ` David Brownell [this message]
2002-10-10 20:35 ` 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-103417677631539@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).