[Splashy-devel] handling signals

Pat Suwalski pats at xandros.com
Mon Mar 20 14:47:39 UTC 2006


Luis M wrote:
> I've added signal handlers to splashy main thread. Now it updates the
> progressbar by 1 tick if a USR1 signal is sent, and by 10 ticks if a
> USR2 signal is sent. This means that it's possible to update the
> progressbar completely from splashy-init without having to write to
> the fifo.

Hey, that's pretty cool.

> The fifo file is not going away, so, don't be alarmed. The reason I
> added this to be able to update the progressbar from initramfs and
> other read-only filesystems.

When one pivots, does the initramfs free itself? One of the big problems 
of running splashy from initrd is that it can only be unmounted after 
splashy exits. I haven't had a chance to investigate initramfs more, but 
I assume it's still a problem and splashy is being re-run by init?

> Now we only need to handle HUP signals correctly, so that splashy
> re-reads the fifo from the new root (pivot_root) after init starts and
> initrd's root tree gets moved to some other structure. I'm open to new
> ideas if you guys have a better way of handling the change of root
> tree...

I don't know if this adds to the problem or is a possible solution, but 
in playing with splashy and directfb in general, I've noticed it's 
possible to "share" the framebuffer. I've had the splashy progressbar 
draw over other framebuffer backgrounds.

I wonder if it would be possible to detect a running splashy and simply 
not reinitialize directfb and redraw the background? That might work and 
have a smooth transition.

Just an idea I've been kicking around.

--Pat



More information about the Splashy-devel mailing list