Re: [PATCH 00/44] commands: add bfetch/buds of command redirection

[Sascha Hauer <s.hauer@pengutronix.de>]

On Mon, Aug 11, 2025 at 02:27:40PM +0200, Ahmad Fatoum wrote:
> Inspired by U-Boot's addition of the ufetch command and the neofetch
> utility for Linux, add a similar command to barebox.
> 
> The command is meant to fancily show off a barebox port with some
> colored ASCII art. The usual alternative is a screenshot of a barebox
> boot up and prompt, which doesn't look fancy, because a first port nearly
> always contains some warning/error messages (e.g. because there is no
> bootsource available and net boot is unconfigured). Example:
> 
> https://raw.githubusercontent.com/a3f/a3f.github.io/refs/heads/master/img/bfetch.png
> 
> This series also includes an abnormal amount of Yakshaving.
> 
> Understandably, we need to export a lot of helpers and lists for bfetch
> to be able to enumerate what features are available at runtime.
> 
> For some things like what CPU we are running on, what uptime we have or
> what's the TEE's implementation ID, we readily have code that prints
> to stdout, but it is not reusable because we do not buffer console
> output streams and thus no command output capture or piping support.
> 
> But even if we had piping, we would need to manipulate strings to split
> lines into key/value pairs.
> 
> Instead, let's rethink the problem: We have commands like cpuinfo, which
> format a table with key/value pairs and print it to out. Then the UNIX
> way would be to use awk/grep/sed/perl or whatever to separate them out
> again.
> 
> Why not skip that and have commands directly return an object
> with key/value pairs (attributes) or more complex data structures
> like PowerShell is able to do?
> 
> This series does exactly that. Device parameters are now associated
> with a struct bobject and that bobject can be returned and consumed
> by commands without requiring association with a device.
> 
> This mechanism should be able to bring support for the pipe operator
> to barebox' shell once the critical commands are adapted to use it and
> there exists a way for commands to report whether they support
> structured I/O or not. As I am still figuring out how to do that,
> I did not include a command that captures structured output to
> a variable, but that would follow in future.

Very nice!

How about something along the lines:

struct device structio_device = {
	.name = "structio",
	.id = DEVICE_ID_SINGLE,
};

static int do_structio(int argc, char *argv[])
{
	int ret;

	active_capture = &structio_device.bobject;

	bobject_del(active_capture);

	/* TODO: merge argv[1-x] to a single string */
	ret = run_command(argv[1]);

	active_capture = NULL;

	return ret;
}

static int structio_init(void)
{
	return register_device(&structio_device);
}
late_initcall(structio_init);

BAREBOX_CMD_START(structio)
	.cmd		= do_structio,
	BAREBOX_CMD_DESC("run with structio")
	BAREBOX_CMD_GROUP(CMD_GRP_INFO)
BAREBOX_CMD_END

With this you could do a

structio cpuinfo; echo $structio.core

We would have to replace characters like whitespaces and hyphens in the
variablenames though.

Sascha

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |