From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Jackson Subject: Re: [PATCH v4 4/4] libxl: fix cd-eject Date: Tue, 16 Feb 2016 17:58:16 +0000 Message-ID: <22211.25400.584104.350999@mariner.uk.xensource.com> References: <1455644269-40358-1-git-send-email-roger.pau@citrix.com> <1455644269-40358-5-git-send-email-roger.pau@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1aVjtE-000277-Lp for xen-devel@lists.xenproject.org; Tue, 16 Feb 2016 17:58:20 +0000 In-Reply-To: <1455644269-40358-5-git-send-email-roger.pau@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Roger Pau Monne Cc: xen-devel@lists.xenproject.org, Wei Liu , Ian Campbell , Alex Braunegg List-Id: xen-devel@lists.xenproject.org Roger Pau Monne writes ("[PATCH v4 4/4] libxl: fix cd-eject"): > Current libxl__device_disk_set_backend implementation tried to guess the > backend of devices with format LIBXL_DISK_FORMAT_EMPTY, which is of course > doomed to fail since the disk is empty. Instead just return early from the > function if an empty disk is detected. > > This fixes cd ejection. DYK when this was broken ? Or, to put it another way, how did this ever work ? ...looking at the code... AFAICT disk_try_backend should succeed for both LIBXL_DISK_BACKEND_PHY and LIBXL_DISK_BACKEND_QDISK. So even before your patch: > } > - memset(&a.stab, 0, sizeof(a.stab)); > + /* Disk is empty, so it's useless to try to guess the backend type. */ > + return 0; > } else if ((disk->backend == LIBXL_DISK_BACKEND_UNKNOWN || libxl__device_disk_set_backend should work. Worse, this change seems to leave disk->backend unset on return from libxl__device_disk_set_backend, which seems quite wrong to me. Ian.