From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: [RFC] x86/hpet: Correct -ENOMEM actions in hpet_fsb_cap_lookup() Date: Thu, 29 Aug 2013 11:14:48 +0100 Message-ID: <521F1F18.6050303@citrix.com> References: <1377708936-4164-1-git-send-email-andrew.cooper3@citrix.com> <521F106202000078000EF4D6@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1VEzKS-0006aI-Ku for xen-devel@lists.xenproject.org; Thu, 29 Aug 2013 10:19:52 +0000 In-Reply-To: <521F106202000078000EF4D6@nat28.tlf.novell.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: Jan Beulich Cc: xen-devel List-Id: xen-devel@lists.xenproject.org On 29/08/13 08:12, Jan Beulich wrote: >> >> This patch is RFC as I didn't actually encounter the problem, nor can think of >> an easy way of actually testing the correctness of the codepath. Chances are >> that if -ENOMEM occurs here, Xen is not actually going to complete booting. > And you're turning a success case (just using fewer than the > available channels) into an error one - it was intentionally coded > this way, and only if there's a problem with that logic I'd consider > a patch valid. > > Jan > Ah - I had not appreciated that possibility, which does make sense. ~Andrew