Re: Our abstract UNIX domain socket support is a mess

[Eric Blake]

On 10/29/20 11:07 AM, Kevin Wolf wrote:

>>>
>>> QEMU's interface is differently messy.
>>>
>>> Our equivalent to struct sockaddr_un is QAPI type UnixSocketAddress:
>>>
>>>     { 'struct': 'UnixSocketAddress',
>>>       'data': {
>>>         'path': 'str' }
>>>
>>> @path corresponds to sockaddr_un member sun_path.  sun_family = AF_UNIX
>>> and socklen_t sizeof(sockaddr_un) are implied.
>>>
>>> We didn't repurpose @path for abstract sockets like the Linux kernel did
>>> with sun_path.  Instead, we added a flag @abstract (default false).
>>> When it's on, we make a binary blob by prefixing @path with a 0 byte,
>>> and pad it with more 0 bytes.
>>>
>>> We added a second flag @tight (default true) to optionally cut the
>>> socklen_t to the end of the string (the terminating 0 byte is not
>>> included).
>>>

> Using magic characters in strings to distinguish different types of
> objects is always wrong in QAPI. If we interpreted leading '@' this way,
> you wouldn't be able to specify a relative filename starting with '@'
> any more.
> 
>> Or, just or by having  explicit flags "abstract" and "tight" to
>> control the behaviour.  The latter is what 'socat' does to allow
>> use of abstract sockets.
>>
>> For QEMU the former approach gives broad interoperabiltiy with
>> userspace applications, so made more sense than using magic "@".
> 
> Boolean flags to distinguish different types are better than parsing
> strings, but still not optimal. Documentation like "only matters for
> abstract sockets" is another hint that we're treating things the same
> that aren't the same.

But why two boolean flags for three sensible states (where it is unclear
if the fourth combination that makes no sense is silently accepted or
loudly rejected), instead of a single tri-state-valued enum?

> 
> The proper way to distinguish two different types is unions. So I think
> the ideal interface would be another SocketAddress variant that could
> then also use base64 instead of str to represent arbitrary blobs, like
> Markus suggested below.
> 
> Probably too late now.

Sadly, you are probably right that we are a bit late to be rethinking
what we expose, since 5.1 is released.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org