Il 09/06/2012 17:30, Laszlo Ersek ha scritto:
> The net init functions all depend on integer optarg values being
> non-negative. Originally this is (or should be...) ensured by
> parse_option_number() [qemu-option.c] calling strtoull(), and "more
> recently" by opts_type_int() in this series.
>
> i. If the opts visitor should be able to parse negative integers
> (currently not necessary for net/netdev types), then I have to change
> opts_type_int() accordingly. To restore the non-negative invariants, I
> must either reintroduce ">= 0" manual checks in the net init funcs
> (conflicts with our frugality), or constrain myself to
> uint8/uint16/uint32/uint64 field types in the json.
I think this is the best choice. Use uint* types.
> +{ 'type': 'NetdevVdeOptions',
> + 'data': {
> + '*sock': 'str',
> + '*port': 'int',
> + '*group': 'str',
> + '*mode': 'int' } }
Lucky, both of these can be uint16 so that assignment to int is safe.
> +{ 'type': 'NetLegacy',
> + 'data': {
> + '*vlan': 'int',
> + 'name': 'str',
> + 'opts': 'NetClientOptions' } }
Just a 32-bit token, int32 will be fine.
> +{ 'type': 'NetLegacyNicOptions',
> + 'data': {
> + '*netdev': 'str',
> + '*macaddr': 'str',
> + '*model': 'str',
> + '*addr': 'str',
> + '*vectors': 'int' } }
Has to be tested anyway against 0x7ffffff (only six "f"s), so uint32 is
good here too.
Paolo
