Am 25.08.2013 12:30, schrieb Klaus Schmidinger: > On 25.08.2013 12:23, Lars Hanisch wrote: >> Hi, >> >> Am 20.08.2013 08:59, schrieb syrius.ml@xxxxxxxxxx: >>> Manuel Reimer <manuel.reimer@xxxxxx> writes: >>> >>>> Hello, >>>> >>>> with event based init systems (in my case systemd) it seems to become >>>> a big issue to startup VDR. >>>> >>>> If you install VDR on a SSD device, then startup gets *really* >>>> fast. Sometimes that fast, that VDR starts before all devices are >>>> initialized. >>>> >>>> I've asked in the systemd mailinglist, if there is any way to get >>>> around this: >>>> >>>> http://lists.freedesktop.org/archives/systemd-devel/2013-August/012716.html >>>> >>>> The result: The "daemon" (VDR) needs some way to detect devices while >>>> runtime. >>>> >>>> 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. >>> >>> Hi, >>> >>> You should be able to achieve this using the dynamite patch and >>> plugin. >>> I would definitey love to see its features merged in main vdr btw :) >> >> As a proof-of-concept I plan to rework the dynamite-patch/-plugin to extract the dynamic device discovering with udev >> as a patch-only-implementation. Klaus, I will not urge you to include this, but I think, if enough people will need and >> test it, maybe in the future we can make you think about it again. :) >> >> Even if you say that you never ever will include it, it won't keep me from writing that patch. I don't have a problem >> to patch my own vdr... :) >> >> My plans: >> - instantiate MAX_DVB_DEVICES cDvbDevice objects at startup > > I don't like this. > > You can, of course, write whatever patch you like, but if the basic approach is > to "instantiate MAX_DVB_DEVICES cDvbDevice objects at startup" then it is most > certainly never going to be included as a core feature. For now I haven't found another solution because several places all over the code (and also in the plugins) use the pointers from the device array. If they change during runtime (or are reset to NULL, maybe inbetween), there are a lot of problems to be expected. Therefore dynamite instantiates "proxy devices" and create "subdevices" with the real access to the hardware. But these proxy devices have its own kind of problems, so I think it's better to implement the hotplug functionality directly in cDvbDevice or even cDevice. It's just the next step on the way, it's way from perfect. I'm just curious if this setup will do better and doesn't change the API too much. :) Lars. > > Klaus > > >> - special adapter number "-1" as "not connected/installed/inactive", such a device will return, that it can't receive >> anything (Provides* functions etc.). >> - start a udev-monitor thread and listen for dvb-subsystem events of adding/removing dvb-cards >> - eval udev attributes on add-events if the card should have a specific device number and pass the adapter to the right >> cDvbDevice object, otherwise interpret the adapter number as cardindex >> - on removing a device, "close" the cDvbDevice (its file descriptors) and set it back to adapter -1 (will solve the usb >> problem mentioned in another mail) >> >> This all is done by dynamite at the moment and is working fine. But since dynamite was the first project to learn about >> udev and all the other things involved, a rewrite is always a good idea now all things are in place. >> Even closing the various file descriptors of the dvb devices doesn't lead to a segfault as some comments in the code >> mention. >> Additional udev will be used to enumerate the dvb devices and some udev attributes may be used to decide if a device >> should be used or not etc. >> >> I just have to work out how the cDvbDeviceProbe thing will fit into this - definitly the plugins must be able to handle >> the special adapter "-1" and must be able to initialise its device aside the constructor. And there must be some kind of >> configuration so the plugins can be told how many cDvbDevice-derived objects each has to instantiate. But it is all >> solvable. >> >> I plan to release the first version of such a patch till end of september, if real life keeps calm the next weeks... :) >> And of course I will design it in such a way that it has to be enabled explicitly with a command line switch so that >> the default behaviour is not changed. >> >> Lars. > > _______________________________________________ > vdr mailing list > vdr@xxxxxxxxxxx > http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr > _______________________________________________ vdr mailing list vdr@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
