[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RFC: OpenRC as Init System for Debian



On 27/04/12 19:33, Tollef Fog Heen wrote:
> ]] Martin Wuertele 
> 
>> * Josselin Mouette <joss@debian.org> [2012-04-27 09:53]:
>>
>>> Le jeudi 26 avril 2012 à 22:29 +0200, Svante Signell a écrit : 
>>>>> Yes of course, because event-driven init systems have *always* been
>>>>> *only* about mounting USB devices. 
>>>>
>>>> Then explain the _real_ reasons for having an event driven boot system!
>>>
>>> BECAUSE THE LINUX KERNEL IS EVENT DRIVEN.
>>
>> That's a reason for udev/mdev, however I still fail to see why this
>> results in the requirement for an event based boot process. 
> 
> A trivial example is $remote_fs isn't satisfied until /srv/somewhere is
> mounted and /srv/somewhere comes off iscsi, which means it requires
> networking to be up, which means network drivers loaded, etc.  So the
> event «network driver loaded» causes ifup to be spawned, which causes
> $network to be satisfied which causes the iscsi daemons to be started
> which causes mount to be called.
> 

A better example is bluetooth.

In my Debian system I have /usr/sbin/bluetoothd running and I don't have
any bluetooth devices on my system... So wouldn't be better that instead
of launching the bluetooth daemon and let it waiting for the day that I
plug a USB bluetooth device (and still I never did that) to just launch
this daemon only when the kernel detects a bluetooth device?


"""
For a fast and efficient boot-up two things are crucial:

* To start less.
* And to start more in parallel.

What does that mean? Starting less means starting fewer services or
deferring the starting of services until they are actually needed. There
are some services where we know that they will be required sooner or
later (syslog, D-Bus system bus, etc.), but for many others this isn't
the case. For example, bluetoothd does not need to be running unless a
bluetooth dongle is actually plugged in or an application wants to talk
to its D-Bus interfaces. Same for a printing system: unless the machine
physically is connected to a printer, or an application wants to print
something, there is no need to run a printing daemon such as CUPS.
Avahi: if the machine is not connected to a network, there is no need to
run Avahi, unless some application wants to use its APIs. And even SSH:
as long as nobody wants to contact your machine there is no need to run
it, as long as it is then started on the first connection. (And admit
it, on most machines where sshd might be listening somebody connects to
it only every other month or so.)

Starting more in parallel means that if we have to run something, we
should not serialize its start-up (as sysvinit does), but run it all at
the same time, so that the available CPU and disk IO bandwidth is maxed
out, and hence the overall start-up time minimized.
""" http://0pointer.de/blog/projects/systemd.html

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Carlos Alberto Lopez Perez                           http://neutrino.es
Igalia - Free Software Engineering                http://www.igalia.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Attachment: signature.asc
Description: OpenPGP digital signature


Reply to: