On 05/19/20 20:20, Philippe Mathieu-Daudé wrote:
> The 'blob_id' argument refers to a QOM object able to produce
> data consumable by the fw_cfg device. The producer object must
> implement the FW_CFG_DATA_GENERATOR interface.
OK, this answers my OBJECT_CHECK() question under patch #1 (in the
negative -- an assert would be wrong).
>
> Signed-off-by: Philippe Mathieu-Daudé <phi...@redhat.com>
> ---
> softmmu/vl.c | 17 +++++++++++++----
> 1 file changed, 13 insertions(+), 4 deletions(-)
>
> diff --git a/softmmu/vl.c b/softmmu/vl.c
> index ae5451bc23..f76c53ad2e 100644
> --- a/softmmu/vl.c
> +++ b/softmmu/vl.c
> @@ -489,6 +489,10 @@ static QemuOptsList qemu_fw_cfg_opts = {
> .name = "string",
> .type = QEMU_OPT_STRING,
> .help = "Sets content of the blob to be inserted from a string",
> + }, {
> + .name = "blob_id",
> + .type = QEMU_OPT_STRING,
> + .help = "Sets id of the object generating fw_cfg blob to be
> used",
> },
> { /* end of list */ }
> },
> @@ -2020,7 +2024,7 @@ static int parse_fw_cfg(void *opaque, QemuOpts *opts,
> Error **errp)
> {
> gchar *buf;
> size_t size;
> - const char *name, *file, *str;
> + const char *name, *file, *str, *blob_id;
> FWCfgState *fw_cfg = (FWCfgState *) opaque;
>
> if (fw_cfg == NULL) {
> @@ -2030,14 +2034,17 @@ static int parse_fw_cfg(void *opaque, QemuOpts *opts,
> Error **errp)
> name = qemu_opt_get(opts, "name");
> file = qemu_opt_get(opts, "file");
> str = qemu_opt_get(opts, "string");
> + blob_id = qemu_opt_get(opts, "blob_id");
>
> /* we need name and either a file or the content string */
(1) Please update this comment. If the option is given, we need the
name, and exactly one of: file, content string, blob_id.
> - if (!(nonempty_str(name) && (nonempty_str(file) || nonempty_str(str)))) {
> + if (!(nonempty_str(name)
> + && (nonempty_str(file) || nonempty_str(str) ||
> nonempty_str(blob_id)))
> + ) {
> error_setg(errp, "invalid argument(s)");
> return -1;
> }
(2) Coding style: does QEMU keep operators on the left or on the right
when breaking subconditions to new lines? (I vaguely recall "to the
right", but I could be wrong... Well, "hw/nvram/fw_cfg.c" has at least 7
examples of the operator being on the right.)
> - if (nonempty_str(file) && nonempty_str(str)) {
> - error_setg(errp, "file and string are mutually exclusive");
> + if (nonempty_str(file) && nonempty_str(str) && nonempty_str(blob_id)) {
> + error_setg(errp, "file, string and blob_id are mutually exclusive");
> return -1;
> }
(3) I believe this catches only when all three of name/string/blob_id
are given. But we should continue catching "two given".
How about reworking both "if"s, *and* the comment at (1) at the same
time, into:
if (!nonempty_str(name) ||
nonempty_str(file) + nonempty_str(str) + nonempty_str(blob_id) != 1) {
error_setg(errp, "name, plus exactly one of file, string and blob_id, "
"are needed");
return -1;
}
(Regarding the addition, nonempty_str() returns a "bool", which is a
macro to _Bool, which is promoted to "int" or "unsigned int".)
> if (strlen(name) > FW_CFG_MAX_FILE_PATH - 1) {
> @@ -2052,6 +2059,8 @@ static int parse_fw_cfg(void *opaque, QemuOpts *opts,
> Error **errp)
> if (nonempty_str(str)) {
> size = strlen(str); /* NUL terminator NOT included in fw_cfg blob */
> buf = g_memdup(str, size);
> + } else if (nonempty_str(blob_id)) {
> + return fw_cfg_add_from_generator(fw_cfg, name, blob_id, errp);
> } else {
> GError *err = NULL;
> if (!g_file_get_contents(file, &buf, &size, &err)) {
>
(4) The "-fw_cfg" command line option is documented in both the qemu(1)
manual, and the "docs/specs/fw_cfg.txt" file.
I think we may have to update those. In particular I mean *where* the
option is documented (in both texts).
In the manual, "-fw_cfg" is currently under "Debug/Expert options", but
that will no longer apply (I think?) after this series.
Similarly, in "docs/specs/fw_cfg.txt", the section is called "Externally
Provided Items" -- but that might not be strictly true any more either.
Maybe leave the current "-fw_cfg" mentions in peace, and document
"-fw_cfg blob_id=..." separately (in different docs sections)? The
"fw_cfg generators" concept could deserve dedicated sections.
Sorry that I can't make a good concrete suggestion. :(
Thanks,
Laszlo
