implementing serialized startup sequence

[Scott James Remnant]

On Mon, 2010-03-15 at 16:51 +0200, Janne Karhunen wrote:
> On Mon, Mar 15, 2010 at 4:03 PM, Scott James Remnant <scott at netsplit.com> wrote:
> 
> >> Implementing 'as fast as possible' bootup often requires implementing
> >> serialized startup sequence(s) we call critical sections.
> >>
> > Do you have any examples of this kind of thing?
> >
> > We didn't find that we needed any such critical sections for the Ubuntu
> > boot sequence.
> 
> That depends on what your goals are. To make this as fast as possible
> we (Maemo & Moblin and now Meego) have implemented several critical
> sections from which the steps to active desktop and dm are the most
> important ones.
> 
Probably depends on your target hardware; for Ubuntu we found that to
get things as fast as possible on netbook machines and up, we actually
wanted to deliberately parallelise tasks that didn't contend on
resources.

Typical example being that we do filesystem checks (heavy I/O) while
udev loads modules and configures hardware (mostly CPU) - then when both
are done, we start the X server.


Not saying your use case is invalid btw ;-)  Just trying to understand
it - I don't have M{aemo,oblin,eego} in front of me - so can't tell what
you're trying to do!

> >> Any ideas what would be the best way to do these upstart wise? Serializing startup
> >> based on 'start on started' will surely do it, but that implies a direct
> >> dependency between tasks A and B and that's not nice. Any other
> >> options?
> >>
> > You could have a job that started things in order:
> >
> >        start on startup
> >        script
> >            start job1
> >            start job2
> >            start job3
> >        end script
> 
> That's an option, but it implies a runner task.
> 
What kind of thing were you thinking instead?

> Moreover, would
> this work with the 'expect' trickery indicating the task startup
> state (ie. is it bound to 'started' event)? We're using all expect
> variants one way or the other and will probably invent some
> more in the future.
> 
Yes.  If you use "expect" (and not "task") then the start command
doesn't return until the expectness is actually running.

Scott
-- 
Have you ever, ever felt like this?
Had strange things happen?  Are you going round the twist?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/upstart-devel/attachments/20100315/d2aea186/attachment.pgp