From mboxrd@z Thu Jan 1 00:00:00 1970 From: Greg KH Date: Thu, 06 Apr 2006 03:12:53 +0000 Subject: Re: [ANNOUNCE] udev 089 release Message-Id: <20060406031253.GA14098@kroah.com> List-Id: References: <20060403171123.GA24860@vrfy.org> In-Reply-To: <20060403171123.GA24860@vrfy.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-hotplug@vger.kernel.org On Thu, Apr 06, 2006 at 03:54:17AM +0300, juuso.alasuutari@tamperelainen.org wrote: > Quoting Scott James Remnant : > > > > If you can convince me why we would want to filter out events on the > > > event generation side instead of doing that on the event handling side. > > > I'm not sure about the idea of controlling the module load order or the > > > other weird things that way, but you may may have good reasons I don't > > > see at the moment. > > > > > The principal reason for us at the moment is in the initramfs; in the > > main system we just plug everything and let the order be damned. > > Indeed, wherever we've found a situation where a module load order is > > necessary (I know of three or four I think at the moment) we've decided > > that the bug is in the driver for requiring that order. > > I just wanted to pop in to confirm that network device modules loading in random > order can be a pain. When interfaces are not always named in the same order, > things can become more complicated than they should be. > This can of course be avoided with rules that bind MAC addresses to fixed names, > but it would be much nicer to have a predictable loading order. Use MAC addressed to create fixed names if you really care about this. Otherwise, the loading order is never guaranteed to be the same (pci bus ids change, usb ids change, etc.) thanks, greg k-h ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642 _______________________________________________ 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