Re: Our abstract UNIX domain socket support is a mess

["Daniel P. Berrangé" <berrange@redhat.com>]

On Thu, Oct 29, 2020 at 01:47:02PM -0500, Eric Blake wrote:
> 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?

This is simply mirroring what  "socat" supports as configuration.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|