From mboxrd@z Thu Jan 1 00:00:00 1970 From: Greg KH Date: Tue, 18 Apr 2006 19:12:59 +0000 Subject: Re: Sound card module loading sequence (was: Re: [PATCH] fix udevtrigger first/default/last ordering Message-Id: <20060418191259.GA3024@kroah.com> List-Id: References: <1145144929.444186616087e@cs1.alpha12.l-secure.net> In-Reply-To: <1145144929.444186616087e@cs1.alpha12.l-secure.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-hotplug@vger.kernel.org On Sun, Apr 16, 2006 at 02:48:49AM +0300, juuso.alasuutari@tamperelainen.org wrote: > Quoting Greg KH : > > > On Thu, Apr 13, 2006 at 02:22:49AM +0300, juuso.alasuutari@tamperelainen.org > > wrote: > > > > I don't completely understand the issue that this patch deals with, but > > does it > > > have something to do with module loading order? This has been giving > > > considerable trouble for people (also previously discussed on this list), > > and > > > is still one major obstacle for udev to reliably replace hotplug. At least > > this > > > is the case for the distribution I assist in developing. > > > > It is? What distro? > > Source Mage. While we don't enforce udev and udev-based module autoloading upon > anyone, it would still be great to have it working completely. > Of course this is just a matter of finding the right rules and writing the right > scripts, which is what I'm set on doing. > > > > Is there a chance that udev could in the future load modules (network, > > audio, > > > etc.) in the same order every time if no significant hardware changes take > > > place? If yes, when and thanks to what changes? If not, what prevents it? > > > > No, as the modules could be loaded in any order if the buses are probed > > a little bit differently next boot time. Or if the BIOS reorders the > > bus numbers. Or another PCI device is added to the system. Or one > > removed. Or any of a zillion different other things happening. > > I do understand that devices being added/removed have this kind of effect, but > the cases I've experienced and seen have had no such reason. Is it the kernel > that's responsible for this, and are there plans to change that behavior? Is > this what I've heard being called a race condition? No, it's not a race condition. It all comes down to how the busses are enumerated by the kernel. For PCI, it usually always is enumerated in the same order, so things are always numbered the same. But, if you upgrade your BIOS, or plug a new device into the PCI bus, things can get renumbered the next time you boot. Also, PCI hotplug devices need to be taken into account here. So you can not rely on the PCI devices always being discovered in the same order. Same thing for USB. Some usb devices can take longer to initialize than others, and cause them to show up in different order at boot time than the last time. So again, you can not rely on the enumeration to always happen in the same order. > > In short, any reliance on the order of modules being loaded, in order to > > name devices properly for a system is broken. Use persistant names, > > that is what udev is for. Look at /dev/disk/ for examples of how to do > > this with block devices today. It works wonderfully thanks to Kay's > > work. > > I've so far ony taken a quick glance at the persistent storage rules, so I can't > say I'm much wiser yet. Maybe studying them in depth will indeed help me. But > before I start on that I wanted to ask if you (or others) have any ideas how to > create sound device numbering bindings. They seem much more confusing than e.g. > network devices. (I recently managed to handle network device naming problems, > so one worry less now.) Name the sound devices based on the pci id. Or the path. Or something else you think might be unique (vendor/product id?, etc.) good luck, 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