implementing serialized startup sequence

[Janne Karhunen]

On Mon, Mar 15, 2010 at 5:19 PM, Scott James Remnant <scott at netsplit.com> wrote:

>> > 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.

Right, some things need parallel setup and some don't. Its
not all black and white.


> 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.

We have been able to remove udev from the critical path and
the same thing goes for almost all module loads. Critical section
is quite clean of all annoyances that would need to be 'hidden'.


>> > 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?

It would be cleaner if init just ran these in defined order
without actual (manual, scripted) runner. 'Manual' startup
makes anything possible, of course. I'm not saying it
makes that big of a difference in real life, I just don't
happen to like solutions that utilize user maintenance
commands for normal startup flow.


>> 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.

Great, thanks.


-- 
// Janne