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

[Geoff Levand]

Jeremy Kerr wrote:
> 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.

Yes, this patch set just does some things that really aren't used.
There are more patches that would make these seem more useful.

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

The second design.  That way you can run one, say the main GUI on the
console, but also run a command line version from a telnet session.

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

A fundamental problem with the current petitboot design is that the
parsing of the menu info is done by the udev helper.  With this design
it is difficult to support user editing of the menu items, since the
editing is done from the UI side, but the UI has no way to parse the
new menu info from the user.

The re-design has the udev helper just passing the device info to the
UI, and the UI does the parsing and menu display.  When a menu item is
edited, the UI then uses the library routines to parse the user supplied
info.

I think this design is the most straight forward to support this feature.
Do you have another idea?

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

Do you see multiple udev helpers, or just one?

The other patches implement this interface with the helper looking in
a well known directory (/tmp/petitboot) for sockets, and writing to each.
The UI apps create a socket when they startup and then run udevtrigger.

The current patches just write the udev info to the sockets, but I
wanted the helper to do some processing of the devices and config
files then write a representation of that to the sockets.  The UI
could then use the library parser routines with that socket
representation or the user edited menu info.

I would like to hear your ideas.

-Geoff