From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59775) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a1AGs-0004U2-DE for qemu-devel@nongnu.org; Tue, 24 Nov 2015 04:52:23 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a1AGo-0005IY-Cx for qemu-devel@nongnu.org; Tue, 24 Nov 2015 04:52:22 -0500 Received: from mx1.redhat.com ([209.132.183.28]:35886) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a1AGo-0005IS-7Q for qemu-devel@nongnu.org; Tue, 24 Nov 2015 04:52:18 -0500 From: Markus Armbruster References: <87si401wpf.fsf@blackfin.pond.sub.org> <2083526024.12459505.1448036588653.JavaMail.zimbra@redhat.com> <564F4E68.8090903@redhat.com> <87si40sfzh.fsf@blackfin.pond.sub.org> <430569618.12530858.1448043657890.JavaMail.zimbra@redhat.com> <874mggo3yc.fsf@blackfin.pond.sub.org> <243512039.12566588.1448050691647.JavaMail.zimbra@redhat.com> <5653A15A.1010703@hpe.com> Date: Tue, 24 Nov 2015 10:52:13 +0100 In-Reply-To: <5653A15A.1010703@hpe.com> (Andrew James's message of "Mon, 23 Nov 2015 16:29:30 -0700") Message-ID: <877fl7912q.fsf@blackfin.pond.sub.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] ivshmem property size should be a size, not a string List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Andrew James Cc: marcandre lureau , Luiz Capitulino , =?utf-8?Q?Marc-Andr=C3=A9?= Lureau , Claudio Fontana , qemu-devel@nongnu.org Andrew James writes: > On 11/20/2015 01:18 PM, Marc-Andr=C3=A9 Lureau wrote: >> Hi >>=20 >> ----- Original Message ----- >>>>> Hash ivshmem been used in anger? If yes, how? >>> >>> Still the question to answer. >>=20 >> I don't expect users to read this ML everyday (anybody >> actually). Personally, I have no clue how widespread ivshmem usage >> is. > > We (Hewlett Packard Enterprise) are using ivshmem as a part of a project > that is set to go public in the next few days: > > https://github.com/FabricAttachedMemory > > Sorry for the premature announcement; I wanted to declare our interest > in ivshmem itself. QEMU 2.1 through 2.4.1 have worked well for our use-ca= se. > >>> Why is this a single device model? >>=20 >> No idea, but I agree it would make sense to have two different devices. > > FWIW, I support splitting the device into memdev and doorbell varieties > as long as a compatibility device is available too. Thanks for your input, it's appreciated. We generally don't just drop interfaces when they have users relying on them. Instead, we deprecate them in favour of replacements. Users are then advised to migrate to the replacement in an orderly fashion. The deprecated interface may go away eventually. We tend to keep it indefinitely unless it's a maintenance burden. In case of ivshmem, I'll take yours and Bruce's note as evidence of use. Orderly replacement is still fine, but outright removal would be rather unkind to its existing users.