U-Boot environment management from userspace

[Vernon Mauery]

Reading U-Boot environment variables from userspace is not difficult, 
but to do it in a standard way, (fw_printenv), it requires a fork and 
exec. We don't have any permissions problems because reading from the 
MTD partition is not restricted. It might be nice, however to have these 
variables exported on D-Bus so that a fork/exec is not necessary, just a 
property fetch.

But writing is a different story. That requires root privileges. To 
architect with a separation of privileges mechanism, this should 
probably be running as a daemon or service that could be spawned via 
D-Bus or something so that ipmid doesn't need root permission to set a 
U-Boot variable.

I see a couple of options:
1) Shoehorn U-Boot variables into the settings daemon so they just show 
up as settings. I am not sure on the details of how this would be done, 
but it might work.

2) Create yet another daemon that would provide a R/W interface 
(probably just using the D-Bus properties interface) that would act as a 
manager of U-Boot environment variables. It might even be able to place 
an inotify watch to get notified when an external process (fw_setenv) 
modifies the environment (like from a script or something) so the D-Bus 
properties could send out a PropertiesChanged notification.

3) Use a one-shot service that parses the 'instance' to extract a 
variable name and variable value. Then the variable could be activated 
by launching ubootenv at foo=bar.service. This would require some fancy 
parameter encoding to make it all work correctly to avoid string 
injections. 

Am I the only one that has a need for this or is there a wider audience 
that would benefit?

Does anyone else already have a solution for this or an opinion on what 
path might be the best?

--Vernon