Received: by 2002:a25:6193:0:0:0:0:0 with SMTP id v141csp787266ybb; Sat, 28 Mar 2020 10:04:39 -0700 (PDT) X-Google-Smtp-Source: ADFU+vs2ZVp0cyee0JnC/NHFx8ZUIxCFCaNNpJ9Qle+Yjlbvh/vQ1FTyN6lMul2nAR/gTPQhfC83 X-Received: by 2002:a05:6830:6:: with SMTP id c6mr3195460otp.84.1585415078917; Sat, 28 Mar 2020 10:04:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1585415078; cv=none; d=google.com; s=arc-20160816; b=BTT7i5+G4uBhan3rmTZu0y5jwfiU6Cq+rESMLLCFu7JfEZpmsBUyevO/mMt4YI3kE5 ZljDMKinK2GqwE25pzmSlnuczMqUBgY5KHM2bmbzvDf8m2FJAaX7ozGFUtcgIVVl2ioN Y3qtUPoJe3V4qrgMbmpqbDgdagkfcx+L7gsOoxvNKpm638Z0gsZKtIimeGi6eeQRqcjx njhxeFIo8sqgclg0YgsIkSmKvcdV2DGi9ir5k5YepcAwG8T7/sF+zT++cjUUb0RD6oAe BgTpqdZi1gW2jmmV2McM3w+QeJjxulBLTSPmXMlh8B+Hcqj1hO6CDsAnoQSKIiquIMQl +lJQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :organization:references:in-reply-to:message-id:subject:cc:to:from :date; bh=OLDQS4SiRr8jgHV4kZlYYZm8GBLCKunRAMzEVvDDITQ=; b=peW3u1xw8LRZ28b/TbP9tlt/LUEDiwFwRsqCYsV+0+gQvrmYXpp9CtG7tzm1hYeapN k3N5x/nmLTJvWaaNmlJsHG2lTUDn9pFXOIWZP/18yQdZnyOO0oXwPdaGZfhZ1VH273hN M8H7yfGIUIX0EaXhd724mOG6wsA60welQkItLz1h+BPY9cIWKn2P+24uFRxauSt22jVp TrKnOASrBKjMCMciUxHAxgm6qG1v6KWWq5gImaTDbEXT6rmGnD4T6U5/1OcdQe20Zk/u rAg7vV1YqZqVTxa929zg9QT0nTeYcs8JOm2989GyfztLrxoytuzH1TUCloFunTiBAj5e w9+A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id c28si4444291otd.215.2020.03.28.10.04.22; Sat, 28 Mar 2020 10:04:38 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726282AbgC1RDx (ORCPT + 99 others); Sat, 28 Mar 2020 13:03:53 -0400 Received: from ms.lwn.net ([45.79.88.28]:54258 "EHLO ms.lwn.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725807AbgC1RDx (ORCPT ); Sat, 28 Mar 2020 13:03:53 -0400 Received: from lwn.net (localhost [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ms.lwn.net (Postfix) with ESMTPSA id E5CAA2F3; Sat, 28 Mar 2020 17:03:52 +0000 (UTC) Date: Sat, 28 Mar 2020 11:03:51 -0600 From: Jonathan Corbet To: Saravana Kannan Cc: Grant Likely , Linux Doc Mailing List , LKML , nd@arm.com, Greg Kroah-Hartman , Andy Shevchenko Subject: Re: [PATCH] Add documentation on meaning of -EPROBE_DEFER Message-ID: <20200328110351.4e50491e@lwn.net> In-Reply-To: References: <20200327170132.17275-1-grant.likely@arm.com> <2885b440-77a5-f2be-7524-d5fba2b0c08a@arm.com> Organization: LWN.net MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 27 Mar 2020 16:55:34 -0700 Saravana Kannan wrote: > > > The infinite loop is a current implementation behavior. Not an > > > intentional choice. So, maybe we can say the behavior is undefined > > > instead? > > > > If you feel strongly about it, but I don't have any problem with > > documenting it as the current implementation behaviour, and then > > changing the text if that ever changes. > > Assuming Greg is okay with this doc update, I'm kinda leaning towards > "undefined" because if documented as "infinite loop" people might be > hesitant towards removing that behavior. But I'll let Greg make the > final call. Not going to NACK for this point. FWIW, kernel developers have to cope with enough trouble from "undefined behavior" already; I don't think we should really be adding that to our own docs. We can certainly document the infinite loop behavior as being not guaranteed as part of the API if we're worried that somebody might start to rely on it...:) Thanks, jon