[Splashy-devel] handling signals

[Luis M]

Hey Pat,

On 3/20/06, Pat Suwalski <pats at xandros.com> wrote:
[snip]
> > 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?

Ummm, perhaps that was an issue with earlier kernels. initramfs was
added on 2.6.12 -- I have not tried putting splashy on initrd, but I
know somebody is doing just that in #splashy (for a knoppix-based
system). There are other issues to keep in mind for them. Let's see
how that goes. Now, in my case, I have not noticed if the initrd
ramdisk gets can't be umounted until splashy exits. At least for me,
splashy exits gracefully before GDM starts, so, I don't get to see
that. I'll do some testing under qemu to see how that goes. As of now,
I did a: mount | grep ini. And there was nothing shown. /initrd is
empty as well.
For a short time splashy was being re-init by splashy-init when init
kicked in (after pivot). I wanted to avoid that and have splash "know"
that it has a new root tree and attempt to read the fifo file from
there. I have not succeeded yet, perhaps that's not the right
approach. Sending a -HUP signal might be the way to do it, but we will
need to handle it gracefully inside splashy.

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

If that's possible that's worthy of investigation. That would
definitely solve the problem without having to bother to handle HUP or
relaunching splashy.

Let us know how that goes if you find the answer...  And keep up the
good work! Keep'em coming.

--
----)(-----
Luis Mondesi
System Administrator
Kiskeyix.org

"We think basically you watch television to turn your brain off, and
you work on your computer when you want to turn your brain on" --
Steve Jobs in an interview for MacWorld Magazine 2004-Feb

No .doc: http://www.gnu.org/philosophy/no-word-attachments.es.html