No man page for xo_emit_field() about libxo HOT 6 CLOSED

xo_emit_field() pointed out to me by @allanjude -- apparently it does exactly what I need for exactly this reason. Unfortunately, I failed to find it when spelunking. Can I suggest an Xref from the xo_emit(3) man page?

from libxo.

Apparently this is, in fact, because it doesn't have a man page. Reopening as a bug report. :-)

from libxo.

I should also comment that you should avoid underscores and upper case field names. Please review the guidelines at:

https://libxo.readthedocs.io/en/latest/faq.html#what-makes-a-good-field-name

I'm guessing these are real concrete register names, so perhaps these don't apply, or perhaps you should use a more flexible schema, like:

<register>
    <name>L1D_CACHE_ACCESS</name>
    <value>10</value>
<register>
<register>
    <name>L1D_CACHE_LIMIT</name>
    <value>1024</value>
</register>

This gives you some benefits:

• allows the receiver to look for specific values (e.g. 'register[name=="L1D_CACHE_ACCESS"]/value')
• allows the receiver to handle values generically ('for-each (register) { call foo(name, value); }')
• allows names that are not xml-compatible (starting with a number)
• allows names to vary while having a simple, fixed schema
• lets you use the native hardware names that violate the field name guidelines

Thanks,
Phil

from libxo.

They are names defined by the architecture spec itself, so we can't change those. I agree that they are not very desirable (for all the reasons you suggest).

I did originally use the schedule you described, but it made things rather more messy to deal with in Python in our lab templates. This model removes a level of data-structure indirection, which does actually simplify things substantially.

from libxo.

Fix is in 'develop' branch:

https://raw.githubusercontent.com/Juniper/libxo/develop/libxo/xo_emit_field.3

Thanks,
Phil

from libxo.

Fixed in libxo-1.5.0

from libxo.