Re: Our abstract UNIX domain socket support is a mess

[Markus Armbruster <armbru@redhat.com>]

Kevin Wolf <kwolf@redhat.com> writes:

> Am 29.10.2020 um 15:02 hat Daniel P. Berrangé geschrieben:
>> On Wed, Oct 28, 2020 at 01:41:06PM +0100, Markus Armbruster wrote:
[...]
>> > Issue#1: our interface is differently ugly, for no good reason
>> > 
>> > Like the Linux kernel, we also appropriate existing @path for abstract
>> > sockets.  With less excuse, though; we could have created a neater
>> > interface, easily.
>> > 
>> > Unlike the Linux kernel, we don't do blobs.  In other words, our variant
>> > of the hack is not general.
>> 
>> The Linux kernel interface is low level and not the way any userspace
>> application exposes the use of abstract sockets. No one wants to
>> specify an abstract socket by listing all 108 characters with many
>> trailing nuls. It would be insane to do this.
>> 
>> There are two ways userspace apps expose abstract socket config.
>> 
>> Either using a leading "@" as a magic substitute for NUL and not
>> supporting a coibfigurable way to distinguish truncated vs full
>> length, just define the desired behaviour for their app. THis is
>> what dbus does to denote its abstract socket paths.
>
> 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.
>
> The proper way to distinguish two different types is unions. So I think

Yes.

> 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.

There are no impossible combinations to ignore or reject, and to
document.  Instead, introspection tells the whole story.

Done this way, we could easily support both a (string, bool tight) for
convenience and base64 blob for generality, if we want to.

But I stand by my opinion that the feature is simply not worth its keep.
To make me reconsider, show me actual uses.

> Probably too late now.

It's too late if we decide it is.

>> > Elsewhere in QMP, we use base64 for blobs.
>> > 
>> > Aside: QMP can do embedded 0 bytes.  It represents them as overlong
>> > UTF-8 “\xC0\x80", though.
>> > 
>> > Not sure the interface is worth fixing now.  Abstract sockets are niche.
>> > In my opinion, we should've said no.
>> 
>> The interface doesn't need fixing - the way it is represented in
>> QEMU is much saner than the low level struct sockaddr_un representation
>> used to talk to the kernel, and is common with other userspace apps.
>> 
>> The use case is to enable interoperability with other apps that use
>> an abstract socket.
>
> Kevin