[Splashy-devel] splashy talking over unix domain sockets

[Tim Dijkstra]

On Wed, 16 Aug 2006 10:02:12 -0400
Luis <lemsx1 at gmail.com> wrote:

> Tim,
> 
> Follow Otavio's advise. Break "trunk" only of course ...
> 
> And yes, we target 2.6.x kernels, but also keeping in mind that some
> BSD users have attempted to port Splashy before. So, try to always be
> as POSIX as you can be so that you don't break other UNICES.
> 
> Keep up the good work.
> 
> Now, the bug in initramfs currently is this:
> 
> 1. splashy opens many filehandles at start
> 2. splashy closes all uneeded filehandles, but a few things stay
> behind: 1 thread listening for keyboard events, 1 thread listening for
> events from the FIFO (which opens and close the file in NON-IO block
> mode)
> 3. when init takes over, "something" sends a kill signal to all
> processes that started from initramfs. 

Really? Any idea what that something is? The linuxrc's I've seen
don't do anything like that, but it's been a while since I studied 
one. I also vaguely remember that processes like udev and portmap 
stay alive when used in the initramfs...

> splashy's dfb lib handles this for us stopping splashy. splashy-init 
> then restarts splashy at /etc/rcS.d/S01splashy-init (so you see two 
> fade-in effects in succession)
> 4. if splashy handles it's own signals (instead of directfb lib) then
> the boot process gets stopped and splashy just sits there waiting...
> the wait is because something else at /etc/rcS.d changes the fonts of
> the console from whatever they were to whatever they should be (UTF8
> for some of us -- unicode. Or back to ASCII). console-screen.sh and
> some other .sh that I can't recall now... see splashy-init comments
> 
> This last thing also happens if splashy is not killed by "something"
> after init takes over (pivot_root or whatever it is that switches init
> from initramfs to /dev no the real filesystem. see linuxrc)

Why do you think using (udp) sockets will help this? Of course using
sockets help because you don't have any open filehandles on the old
filesystem, but your comments seem to imply that having splashy running
during console-screen.sh triggers the bug.

grts Tim

Ps. I managed to get uswsusp display a penguin + progress bar on suspend.
Not on resume yet.