<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
    <style type="text/css"> body {font-family: Trebuchet MS, sans-serif; font-size: small;} </style>
  </head>
  <body>
    Hi,<br>
    <br>
    On 05/03/2011 07:25 PM, Scott James Remnant wrote:
    <blockquote
      id="mid_BANLkTi=zvJrO+7fjZZUNMZOX+46xoOFpCQ_mail_gmail_com"
      cite="mid:BANLkTi=zvJrO+7fjZZUNMZOX+46xoOFpCQ@mail.gmail.com"
      type="cite">
      <div>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.</div>
      <div><br>
      </div>
      <div>
        Let's first take the tuners as an example.</div>
      <div><br>
      </div>
      <div>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.</div>
      <div><br>
      </div>
      <div>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.</div>
      <div><br>
      </div>
      <div>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.</div>
      <div><br>
      </div>
      <div>It's also supposed to not use names like /dev/video0 because
        the 0 bit can change for any one device during reboots.</div>
      <div><br>
      </div>
      <div><br>
      </div>
      <div>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:</div>
      <div><br>
      </div>
      <div>  start on <result of running a script></div>
      <div><br>
      </div>
      <div>but that's an expensive thing to do on startup - for a start,
        what are that scripts dependencies?</div>
      <div><br>
      </div>
      <div><br>
      </div>
      <div>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.</div>
    </blockquote>
    <br>
    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.<br>
    <br>
    <blockquote
      id="mid_BANLkTi=zvJrO+7fjZZUNMZOX+46xoOFpCQ_mail_gmail_com"
      cite="mid:BANLkTi=zvJrO+7fjZZUNMZOX+46xoOFpCQ@mail.gmail.com"
      type="cite">
      <div><br>
      </div>
      <div>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.</div>
      <div><br>
      </div>
      <div>A change of mythtv configuration results in a change of boot
        configuration.</div>
    </blockquote>
    <br>
    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.  <br>
    <br>
    The job could declare it's start on (starting mythtv-backend and
    started mysql).<br>
    <br>
    Am I to understand that this would resolve it properly by blocking
    mythtv-backend's startup until mysql's startup completed?<br>
    <br>
    If for some reason the MySQL server is on a remote machine, you just
    wouldn't install mythtv-backend-master.<br>
    <br>
    <br>
    <div class="moz-signature">-- <br>
      <title></title>
      <font face="Helvetica, Arial, sans-serif" size="-2"><font
          color="#999999">Mario Limonciello</font><br>
        <font color="#666666"><a class="moz-txt-link-abbreviated" href="mailto:superm1@ubuntu.com">superm1@ubuntu.com</a></font></font>
    </div>
  </body>
</html>