Kevin Wolf <kw...@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
