[vdr] VDR needs some way to detect new tuners on runtime...
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
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). ;-)
More information about the vdr