[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Our abstract UNIX domain socket support is a mess
From: |
Daniel P . Berrangé |
Subject: |
Re: Our abstract UNIX domain socket support is a mess |
Date: |
Fri, 30 Oct 2020 09:16:18 +0000 |
User-agent: |
Mutt/1.14.6 (2020-07-11) |
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 :|