[vdr] VDR needs some way to detect new tuners on runtime...

Matthias Schniedermeyer ms at citd.de
Tue Aug 20 11:28:58 CEST 2013


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



More information about the vdr mailing list