Kay Sievers wrote: > On Tue, Jan 26, 2010 at 16:22, Greg KH <greg@xxxxxxxxx> wrote: > >> On Tue, Jan 26, 2010 at 03:36:39PM +0100, Andreas Besse wrote: >> >>> i have a system with multiple DVB cards of the same type and want to >>> specify the order of the devices /dev/dvb/adapterX. The device plugged >>> into the physical PCI slot 1 on the mainboard should be assigned to >>> /dev/dvb/adapter0 and the card in PCI slot 2 should be assigned to >>> /dev/dvb/adapter1. >>> > > We usually do not change kernel names, but create meaningful named > symlinks to them. Stuff gets confused when /sys and /dev get > out-of-sync. > > >>> In the following post >>> http://thread.gmane.org/gmane.linux.kernel.pci/7446/focus=7467 there >>> is mentioned that the order of the devices can be specified by using >>> udev rules. >>> > > The order can usually only specified by unconditionally loading kernel > driver modules in a defined order. This usually works fine for PCI > devices, but can obviously not work if there are USB devices involved. > > >>> But how this can be done? Which information in /sys can be used to >>> determine which DVB device is connected to which specific slot? >>> >> Did you try the latest version of udev that has the persistant rules for >> the v4l devices in it and look at the symlinks that are created to see >> if they solve the problem for you? >> > > Looking at it now, I think we only do video4linux, not the DVB stuff, > which has its own class. But it should be possible to implement a > similar model for /dev/dvb/by-id, /dev/dvb/by-path without much > problems. It's just, that nobody really cared so far. > > Thanks, > Kay > but how can these persistent rules solve the issue that the order of PCI Slots (PCI Bus IDs) is not deterministic and totally random determined at boot? I think the udev rules only can use informations which are already available in /sys/ ? regards, Andreas Besse -- To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
