From: Kay Sievers <kay.sievers@vrfy.org>
To: linux-hotplug@vger.kernel.org
Subject: Re: usbcore vs. udev
Date: Wed, 26 Jan 2005 12:43:15 +0000 [thread overview]
Message-ID: <1106743395.6865.15.camel@localhost.localdomain> (raw)
In-Reply-To: <20050125184727.GA13793@nostromo.devel.redhat.com>
On Tue, 2005-01-25 at 23:12 -0500, Bill Nottingham wrote:
> Greg KH (greg@kroah.com) said:
> > > modprobe usbcore yields no events to udev, as far as I can tell
> > > by putting a catchall script in /etc/dev.d/default.
> >
> > Nor should it. Why would you think it should?
>
> Only because it emitted events on remove. :)
I can't reproduce this here. I expect, with 050 you don't get any event
in dev.d/, not for "remove" nor for the "add" event of usbcore.
The events for class creation are just recently introduced by a change
in the driver core and I blacklisted these for udev with version 049.
> > Ah, you mean the class add and remove. Hm, I think we don't emit those
> > because those are classes (not class_dev), and at remove time we don't
> > know to not emit them. I'm considering always emiting them at add also,
> > but it might mess up some userspace stuff, so I'm trying to be cautious
> > and test it out a lot first.
> >
> > But again, udev doesn't care about these events, nor should it.
>
> Probably not. Perhaps hooking into hotplug for the class is better;
> what I was originally looking at is hooking into the class/device
> plug for the mounting of usbfs.
Yes, hotplug.d/ should work fine for this. With the hotplug events
managed by udevd (Fedora devel already swiched to it) the only
difference between hotplug.d/ and dev.d/ is that /dev.d fires only on
node creation/removal. Everything else, the environment, the
availability of the node or wait_for_sysfs is exactly the same.
Thanks,
Kay
-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
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:[~2005-01-26 12:43 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-01-25 18:47 usbcore vs. udev Bill Nottingham
2005-01-25 22:34 ` Kay Sievers
2005-01-25 22:46 ` Greg KH
2005-01-26 1:33 ` Bill Nottingham
2005-01-26 1:55 ` Bill Nottingham
2005-01-26 3:38 ` Greg KH
2005-01-26 4:12 ` Bill Nottingham
2005-01-26 12:43 ` 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=1106743395.6865.15.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.