On 20.08.2013 10:42, Klaus Schmidinger wrote: > On 20.08.2013 10:20, Manuel Reimer wrote: > >On 08/20/2013 10:12 AM, Klaus Schmidinger wrote: > >>>So my question to Klaus: Is there something like this planned or would > >>>a patch be accepted which adds a feature like this? As far as I know a > >>>new dependency (libudev) would be needed. > >> > >>I wouldn't like to add a dependency to libudev. > > > >So how could an alternative approach look like? Maybe it could work with "inotify" to see when new devices are added below /dev, but I think this will also require new dependencies. > > > >The easiest way may be: Call the existing code for finding the tuners not only once but every X seconds. > > > >> NUMADAPTERS=3 > >> while [[ `find /dev/dvb -name 'adapter*' | wc -l` -lt $NUMADAPTERS > >>]]; do sleep 1; done > >> runvdr ... > >> > >>could be used to count the number of adapters, and check that number in > >>a loop > >>against the expected number of adapters. > > > >This works for *one* system and only if the user manually sets the number of adapters. How could this be done in a "automagic" way to allow users to just plug the tuner and reboot? > > As I wrote before, VDR needs all devices to be ready when it starts, otherwise > any configuration parameters that refer to "device numbers" might not work. You say "All devices have to be there, because there can be configuration by device-number". Me thinks, why configuration by device-number? Configuration by index isn't always the best, there could be a configuration by name/UID or something link that. Sure you get different problems, so it's a judgement call what set of problems is the lesser evil. For e.g. where you could formerly just swap a card and it still "just worked", you then would have to configure something. BUT adding another card would not mangle the configuration regardless of the new card getting ordered before the older card or not. I think a named configuration is a requirement for proper "hotplugability", USB devices for e.g. are inherently hotplugable. It's basically the same thing we nowadays have with networking. In the past the first found NIC was eth0. Assuming there is only 1 NIC in a computer, in the past it "just worked" when you swapped the NIC. Nowadys you have to do something, because by default udev will (re-)name it eth1 and eth0 goes MIA. BUT adding a second NIC is guranteed to not mangle eth0, even if the kernel would initially name it eth0, udev will fix that. So there is pro/contra for index vs. name based configuration, i personally prefer name base configuration. It's usually easier to debug and behaves deterministicly. Especially as device-discoverty/-initialization is NOT guranteed to be deterministic and/or long-term stable. Which means even if something works(/is deterministic) with kernel X, there is no guarantee that X+1 with behave identical. And when implemented with aliases like "device0" (or aliased in such a way (if possible) that current configuration files are still valid) the configuration by index would still be possible, so the user could even choose which set of problems they want (I.E. Into which foot they prefer to shoot themselves). ;-) -- Matthias _______________________________________________ vdr mailing list vdr@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
