From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kay Sievers Date: Wed, 24 Aug 2005 19:37:54 +0000 Subject: Re: udevsynthesize as a udevstart+coldplug replacement Message-Id: <20050824193754.GD9483@vrfy.org> List-Id: References: <20050823191542.GA29091@vrfy.org> In-Reply-To: <20050823191542.GA29091@vrfy.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-hotplug@vger.kernel.org On Wed, Aug 24, 2005 at 01:14:06PM +0200, Olivier Blin wrote: > Kay Sievers writes: > > > Here is "udevsynthesize" a possible replacement for the udevstart/coldplug > > combination we currently have. Usually very early in the boot process, it > > gets all available devices from sysfs and synthesizes the events these > > devices would have generated at creation time. > > That's mostly udevstart + async mode + the (really much improved) > coldplug support I proposed some days ago :-) > Though, it would have been nice to announce you'd handle that in the > previous "USB coldplug" thread, it looked like you were not in favor > of pushing such bus coldplug support. As pinted out earlier, it's a very different approch with complete different problems to do it async. > I'd still like a --disable-bus= option so that distro vendors can > forbid bus coldplug they don't like. > I'm not sure most distro are ready to have udevstart automatically > load modules on the pci bus. For example network and sound drivers are > often handled separately. > Should I take care of this patch? _Not_ handling these events is just a special case of handling it, so a rule can prevent the event from doing anything. I prefer a single source of policy as long as this is possible. > And why not keeping the udevstart name? The previous udevstart can be > replaced by this udevsynthesize. They fulfill the same tasks, the only > difference is async mode + bus coldplug, does it justify a name > change? As said earlier, udevstart is the most critical part of udev. We should not play around with that. And Olaf was right, the name is misleading and should change anyway. :) Thanks, Kay ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ 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