[systemd-devel] simple systemd boot status

Gustavo Sverzut Barbieri barbieri at profusion.mobi
Sun Sep 26 19:52:02 PDT 2010


On Sun, Sep 26, 2010 at 9:54 PM, Lennart Poettering
<lennart at poettering.net> wrote:
> 1;2591;0cOn Tue, 21.09.10 23:39, Gustavo Sverzut Barbieri (barbieri at profusion.mobi) wrote:
>
>> Hi all,
>>
>> I've wrote a proof of concept of a simple boot status for systemd.
>> Yeah, I know fedora folks have their super-duper plymouth, but I don't
>> want such thing just to show some progress.
>
> Why not?

I looked at its code, it's doing hell lot of things, with lots of
deps, just to get a simple progressbar on screen. Sure, we could look
fancy, but just it would help to trash my IO even more :-/  I want a
really simple binary that links to as less libs as possible and show
the bare minimum... If I was to use plymouth then I'd rather do
something in EFL, as it's more efficient and I'll need it later (BTW,
plymouth creates its own rendering canvas with multiple backend,
that's just pointless, why not use Evas instead?)

Anyway, right now I'm going even more radical and whenever I have time
I'll try to figure out how to do MacOSX way of boot: do nothing. The
bootloader could setup some graphics and draw an image, the kernel
should not reset it, then just X would take care of it.


>> My current version is at
>> http://git.profusion.mobi/cgit.cgi/gustavo/systemd-bootstatus/ and
>> provides a simple text-version. By default itwill allocate tty12,
>> clear the screen and draw a small ascii box in the center with the
>> current progress it polls every 0.1s.  The final binary is around 16kb
>> stripped, so quite simple and should not impact your boot.
>
> Hmm, note that console output is actually really slow, and hence this
> might actually influence your boot more than expected.

not an issue for me, the commands are pretty simple. But later on I'll
add a very very simple graphical version using fbcon and kms.


> I am actually thinking of sending out bus signals every time the
> progress increases (though probably rate limited to 1 msg per 100
> ms). It might be smarter to update your progress screen with those
> signals then, instead of polling the progress...

it would update for a not good reason, that's fine.


>> Later on I plan to add a fbdev output and even later on, if time
>> allows, I plan to add a version with kms. NONE of these will include
>> image or font support, they will just setup the graphics mode and draw
>> a progress bar. The idea is not to link with libraries that are not
>> required (otherwise I'd use EFL, that is much simpler and efficient
>> that all the replication done in plymouth BTW).
>
> Hmm, what's your problem with plymouth? It also draws to fbcon.
>
> Note that I plan to add some special systemd/plymouth love soon,
> e.g. pass off status updates to plymouth directly, via a private ply socket.

a private handle would be helpful instead of relying on dbus to be up.

Actually this approach I use have couple of drawbacks that made me
halt further developments:
   - systemd takes too long to start my service, even if i force it to
be one of the first (and thus before dbus, so I need to keep checking
the dbus socket).   It would be good to have a way to tell systemd to
start the "status" process as soon as possible. Of course the other
solution is my program to be the init= in the kernel command line,
with it forking the actual status monitor and then exec systemd...
People that use initrd will always be forced to that, but what about
have it in systemd?

   - systemd starts the last process soon (about 9s), but to have
something displayed in my X it takes around +8s, at 17s.  That means
that around half of the time my status shows "100%" but user gets
nothing. Okay, I could try some trick to be notified of DM being up,
but that looks like depend on DM (and I don't use GDM).


-- 
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--------------------------------------
MSN: barbieri at gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202


More information about the systemd-devel mailing list