Il giorno ven, 04/04/2008 alle 19.17 +0200, Denys Vlasenko ha scritto:
> On Friday 04 April 2008 11:27, Michele Sanges wrote:
> > Hello,
> >
> > while fbsplash works well in root fs, it doesn't work when started from
> > an initrd. It exhibits this behavior:
> >
> > 1. the nash shell, used in initrd, can't start the applet in background;
> > it blocks forever the loading process.
> >
> > ==> I added back the code to fork the process (if this can be
> > acceptable).
>
> I'm sorry, but it is not acceptable. In Unix, each tool should do
> one thing. fbsplash should not be hardwired for one application
> (boot splash). What is someone needs to want for fbsplash to finish?
>
> Make it so that people who want to background it, can do it,
> and the rest is not forced to do so.
I think I have not understood what kind of use you thought for fbsplash.
>From my last patch:
> fb_drawimage();
>
> if (!fifo_filename)
> return EXIT_SUCCESS;
>
> // when run from initrd, the nash shell can't put it in background
> // forks the parent process
> pid = fork();
I view only two pratical applications of fbsplash.
The first one is to show a ppm image; fbsplash in this case isn't
daemonized as shows above, and return immediately.
The second one is during the boot phase of our embedded device, to
distract the operator and give the impression of a shorter boot
time :-) . In this case fbsplash must be placed in the background.
I really do not find very useful send messages from stdin for seeing the
progress bar to move, so I think it would be better if fbsplash could
demonize himself, without remove freedom to anyone.
> If you are using a shell which is incapable of backgrounding
> processes, write a helper tool, say:
>
> daemon <cmd> <params>
>
> which forks, child execs "<cmd> <params>", and parent exits.
Is there such tool in busybox? Is this the start_stop_daemon applet?
> > ==> I substitute the file manipulation library functions (fopen,
> > fgetline, fclose..) with the system one (open, read, close..) and thus
> > it works.
>
> Well, it would be nice to understand why it makes a difference.
I tried your latest version within an initrd based on nash shell, adding
to it the code for daemonized. It doesn't receive the commands from the
fifo until it reach the root fs. Here it begins to move the progress
bar.
After many tests :-( , I found that the difference is the version of the
'echo' used in initrd to send information to fbsplash.
The nash shell uses his own builtin version of 'echo' command that, for
some reasons, seems to be incompatible with your version of fbsplash.
Indeed if in the initrd I go to replace all calls to the builtin echo
with "busybox echo", your version of fbsplash begins to receive
commands.
Now the problem is why my last version of fbsplash works properly also
with the builtin version of 'echo'?
Here an strace of the two fbsplash versions, in root fs and with the 'normal'
echo.
# my latest version
24682 close(3) = 0
24682 munmap(0xb7c79000, 4096) = 0
24682 open("/etc/fbsplash/fbsplash_fifo", O_RDONLY|O_LARGEFILE) = 3
24682 open("/etc/fbsplash/fbsplash_fifo", O_WRONLY|O_LARGEFILE) = 4
24682 read(3, "10\n", 32) = 3
24682 read(3, "20\n", 32) = 3
24682 read(3, "30\n", 32) = 3
24682 read(3, "40\n", 32) = 3
24682 read(3, "50\n", 32) = 3
24682 read(3, "exit\n", 32) = 5
24682 close(3) = 0
24682 close(4) = 0
24682 exit_group(0) = ?
# your latest version
21592 close(3) = 0
21592 munmap(0xb7cd7000, 4096) = 0
21592 open("/etc/fbsplash/fbsplash_fifo", O_RDONLY|O_LARGEFILE) = 3
21592 open("/etc/fbsplash/fbsplash_fifo", O_WRONLY|O_LARGEFILE) = 4
21592 fstat64(3, {st_mode=S_IFIFO|0644, st_size=0, ...}) = 0
21592 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0xb7cd7000
21592 read(3, "10\n", 4096) = 3
21592 read(3, "20\n", 4096) = 3
21592 read(3, "30\n", 4096) = 3
21592 read(3, "40\n", 4096) = 3
21592 read(3, "50\n", 4096) = 3
21592 read(3, "exit\n", 4096) = 5
21592 exit_group(0) = ?
The only difference that I see are the 'fstat' and 'mmap' calls. Any idea?
> > After reading, the buffer is
> > scanned in order to take the last command line.
>
> + cmd_buf[nlen] = '\0';
> +
> + // when we have many buffered lines already in the pipe,
> takes the last one.
> + p = cmd_buf;
> + last_cmd = cmd_buf;
> + while (((p = strchr(last_cmd, '\n')) != (cmd_buf + nlen - 1))
> && (p != NULL)) {
> + last_cmd = (p + 1);
> + }
>
> This will break if we get, say, 34 byte long string:
>
> "1\n2\n3\n.....\n34\n"
>
> read will eat 32 bytes: "1\n2\n3\n.....\n3"
>
> and you will display 3% bar.
For the use of fbsplash as bootsplash, you before starts the daemon and
then you send commands to it so, a buffer of 32 bytes is more than
enough.
Regards.
Michele
_______________________________________________
busybox mailing list
[email protected]
http://busybox.net/cgi-bin/mailman/listinfo/busybox
