[PATCH 6/19] bhyve: add basl support for length fields

[corvink]

Summary

ACPI tables have different layouts. So, there's no common position for
the length field. When tables are build by basl, the length is unknown
at the beginning. It has to be set after building the table.

This is the 6. patch required to merge D36983

[markj]

usr.sbin/bhyve/basl.c

49

Looks like this can be static.

113

I think _set_lengths() would be a bit better as a name.

116

121

Shouldn't you assert that the offset is within the bounds of the table?

236

Similarly I think these should simply be assertions, since this check can only fail due to a programming error.

[corvink]

• make use of assertions as suggested by reviewers
• turn basl_lengths into a member variable of basl_table to avoid global variables and backpointer

[jhb]

usr.sbin/bhyve/basl.c

120

I wonder if what you kind of want actually is a helper function that writes an integer in little endian format to a buffer but takes a size, something like:

static __inline void
basl_store_int(void *pp, uint64_t val, size_t len)
{
    char buf[8];

    le64enc(buf, val);
    memcpy(pp, buf, len);
}

You could use this in the earlier commit that appends an integer to a table, and you could use it here as:

basl_store_int(table->data + length->off, table->len, length->size);

[corvink]

• make use of basl_le_enc helper