Upstart config file generation

Mario Limonciello superm1 at ubuntu.com
Wed May 4 00:50:34 UTC 2011


Hi,

On 05/03/2011 07:25 PM, 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.
>
> It's also supposed to not use names like /dev/video0 because the 0 bit 
> can change for any one device during reboots.
>
>
> 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?
>
>
> I'm increasingly thinking that this model is backwards though - it's 
> all well and good probing every device on boot, but it's *expensive*. 
> We really don't need to care until something starts that cares. If we 
> knew what wanted the device information, we could delay all of that 
> probing until it was actually needed.

I agree it makes most sense to solve this by allowing the backend to 
find new tuners after it's running if they're hotplugged/initialized 
later.  Isn't that part of the goal that should be accomplished with the 
new HTTP backend configuration coming in MythTV 0.25?  My understanding 
is that the backend was going to have to be running for it to work, 
meaning it should be able to do add/remove tuners without going through 
it's whole startup code sequence again.  It's a logical extension to me 
at least.

>
> And the backend is another interesting case. We need to know what 
> MythTV needs - it needs MySQL, but it's configured onto a remote 
> address, so it doesn't need the local server - it just needs local 
> client software and a route to the remote server.
>
> A change of mythtv configuration results in a change of boot 
> configuration.

Can this maybe be solved by an additional upstart job that lives in 
mythtv-backend-master?  The intent of the meta package is to declare 
that this machine is a master backend with a MySQL server residing on 
the machine.

The job could declare it's start on (starting mythtv-backend and started 
mysql).

Am I to understand that this would resolve it properly by blocking 
mythtv-backend's startup until mysql's startup completed?

If for some reason the MySQL server is on a remote machine, you just 
wouldn't install mythtv-backend-master.


-- 
Mario Limonciello
superm1 at ubuntu.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/upstart-devel/attachments/20110504/312678ba/attachment.html>


More information about the upstart-devel mailing list