[PATCH] Add support for scrolling boot log messages

[Pali Rohár]

On Tuesday 13 September 2011 22:28:02 Ray Strode wrote:
> Hey again,
> 
> I looked through your patch and have some thoughts.
> 
> One thing I don't really like in the patch is the special
> prefixed messages.  Messages are supposed to be human
> readable, translated text strings.
> 
> Stuff like "Press I for interactive start up" or "Press Escape
> to view detailed boot messages"
> 
> We do have something that is supposed to be machine parseable.
> That's 'plymouth update --status=some-milestone' which tells
> the splash plugins about certain distro specific events in the
> boot process. It's sort of encodes the expectation that a
> service starts and finishes in one go, though, so it's not
> ideal for capturing things that don't start instantaneously.
> 
> We also have a way to say "there was an error during boot". 
> That's 'plymouth report-error'  .  It just says that there was
> an error, though, giving no context about what that error is,
> so it's not very useful.
> 
> Neither of these are exactly what you need, but they illustrate
> that we really should have "control information" about boot
> progress encoded in the protocol and not the message payloads.
> 
> I think what you're looking for is a way to tell the splash
> plugin 1) about a new (potentially slow) operation that is
> initiated 2) when and how the operation completes
> 
> So we probably need to augment the protocol to support that.
> Maybe some new "register-operation" command like:
> 
> plymouth register-operation --id=some-id --name="some human
> readable name here" --initial-status=some-starting-status
> 
> and then a new optional --operation-id flag to "plymouth
> update"
> 
> plymouth update
> --operation-id=some-id-previously-passed-to-register-operation
> --status the-latest-outcome-of-the-operation
> 
> This way you could do, e.g,
> 
> plymouth register-operation --id=some-random-job --name="some
> random job" --initial-status=starting
> plymouth  update --operation-id=some-random-job
> --status=finished
> 
> and the splash plugin could do
> 
> Starting some random job... [ok]
> 
> but if you did
> plymouth update --operation-id=some-random-job --status=failed
> 
> then it would do
> 
> Starting some random job... [failed]
> 
> The splash plugin could keep track of which line in on the
> screen is which operation and automatically add the
> appropriate status text to the right line.
> 
> Make sense?
> 
> A few more thoughts:
> 
> - I don't think we would want to add those kinds of messages to
> the text plugin.  the point of the text plugin, in particular.
>  The point of that plugin is to hide boot messages.
> - make sure the patch is against an upstream tree when
> submitting it upstream - thanks for putting effort into
> working on plymouth. I'm sorry it took so long to reply.  Feel
> free to aggresively poke me on list or in #plymouth if I don't
> respond within a reasonable time frame.
> 
> --Ray

Hi, sorry for long delay, but I did not have time last year and I 
then forgot about my patch...

Now I read your suggestion and it sounds good.

I have one question about implementation, how to implement 
sending command this command from client to server?

$ plymouth update --operation-id=<id> --status=<status>

Current client/server plymount protocol support only passing 
command name and command argument. Command name for update is

#define PLY_BOOT_PROTOCOL_REQUEST_TYPE_UPDATE "U"

and current argument is status name (const char *). Command and 
argument are passing to function ply_boot_client_queue_request.

How to add to this protocol/function operation-id argument?

-- 
Pali Rohár
pali.rohar at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.freedesktop.org/archives/plymouth/attachments/20120627/edb4608a/attachment.pgp>