[Cbe-oss-dev] [patch 0/9] petitboot: create petitboot library

[Jeremy Kerr]

Hi Geoff & Yuji,

> The end goal of the library is to move common code to the library to
> allow the creation of both graphic and command-line petitboot
> applications that link to the core routines in the library.

OK, I think it's a good idea to allow different UIs, but I'm not 
convinced that this patch set actually helps. A lot of the code in this 
proposed library isn't actually shared at all.

What are your goals for having a new UI? I can see two possible 
approaches:

1) We have multiple different UIs, but only ever run a single UI at any 
one time. When the device discovery processes  (ie, the udev-helper 
binaries) find a boot option, they connect to the UI socket and send an 
'found a new boot option' message. If someone tries to start another UI 
when there is already one running, it'll fail to create the socket (ie, 
ADDRINUSE). To switch between UIs, we need to kill the first, start the 
second, then re-run the device discovery code (ie, with udevtrigger). 
This is pretty much how we do things at the moment, and shouldn't take 
much code to implement another UI.

2) We allow multiple UIs to be run at once. This is a little trickier, 
as the device discovery processes may need to inform *multiple* UIs that 
there is another boot option available, and UIs may be started after 
devices have already been discovered (and so need to know the current 
state of already-discovered devices). Ideally, we would do this without 
running a separate daemon.

Now, to do either of these options, there should be some shared code 
between UIs, but this would be much smaller than the petitboot.so 
library that these patches are adding. As I see it, the only code that 
should be shared is the 'server side' of the socket interface. This is 
basically the top-level devices.c (which is pretty GUI-specific at the 
moment, but we could make it more generic). This is probably small 
enough just to statically link to either GUI, and not require a library 
at all.

There is no need to have any of the parsing code in the shared library, 
as there should only be one binary that does this (ie, the udev helper), 
and it's independent of the UI that is being used.

I think the main challenge with multiple UIs is an appropriate interface 
between the UI and the udev helpers, rather than the current point-to-
point one with a single socket. I'm looking at an alternative at the 
moment, feel free to discuss.

Cheers,


Jeremy