Upstart config file generation

[Jan Ceuleers]

On 04/05/11 02:25, Scott James Remnant wrote:
> This is definitely one of those use cases where it's been difficult to
> find a proper middle ground between the two projects. If we can crack
> this one, I think we could accomplish anything.
>
> Let's first take the tuners as an example.
>
> The current model is that the device is visible on the bus by
> vendor/device id/class etc. which during a udev "trigger" run results in
> modprobe being called to load the driver. This results in additional
> devices being created in the kernel, which trigger further udev rules to
> load firmware, probe the resulting devices to populate the udev db, run
> additional scripts and software to configure and calibrate the device
> and then announce to userspace that the device is ready.
>
> Userspace software would on startup listen for futher events, and then
> iterate the available devices and match the probed information against
> its configuration. As events come in it would also match these against
> its configuration.
>
> Obviously MythTV doesn't quite do this either, but that's the model it's
> supposed to be following. It's supposed to be startable at any point,
> and deal with configured devices being missing.

Right, so this is the "the app is broken" school of thought. The proper 
solution then is to fix MythTV rather than Upstart.

> It's also supposed to not use names like /dev/video0 because the 0 bit
> can change for any one device during reboots.

I don't think MythTV has any option but to use the /dev/video* or 
/dev/dvb/adapter* device nodes because those are what video4linux exposes.

Ensuring that the names are persistent across boots is generally 
accomplished by means of udev rules, as explained here:

http://www.mythtv.org/wiki/Device_Filenames_and_udev

> Now obviously that hasn't been the Upstart model, that's maybe more the
> "dream" model (and systemd model). Upstart has tried to be flexible
> towards existing software - thus the complex "start on" lines. In which
> case you kinda end up wanting:
>
>    start on <result of running a script>
>
> but that's an expensive thing to do on startup - for a start, what are
> that scripts dependencies?

Also, I'm not sure how this script would capture the appropriate udev 
events (but then I know very little about udev). If this is in any way 
complicated or expensive then this would be a shame, since Upstart 
already has the necessary udev hooks.

I was more thinking about an ugly hack such as the following:

     start on (<base dependencies>
     #include <mythtv-tuners/*.conf>
     )

Each tuner would have a corresponding file in /etc/init/mythtv-tuners 
with contents such as the following

     # /etc/init/mythtv-tuners/tuner1.conf
     and pvrusb2-device-added KERNEL=sn-7157879

which would be added to the start on stanza.

This makes it easier for applications to modify the startup triggers 
without having to generate the entire Upstart configuration file. The 
latter would require a (preferably standardised) way of combining a 
generic template with installation-specific triggers. The former rolls 
this into Upstart proper, although perhaps a cleaner way of doing this 
can be found.

This still leaves us with the problem of how to generate these 
tuner*.conf files, the procedure for which currently requires manual 
discovery of the appropriate udev triggers and a reboot or two. But at 
least the above is a (small) step towards automatic flow-through 
provisioning of the Upstart configuration.

Thanks, Jan