From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id DF94EC433EF for ; Mon, 11 Oct 2021 08:02:12 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id BEBFE60D07 for ; Mon, 11 Oct 2021 08:02:12 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234734AbhJKIEK (ORCPT ); Mon, 11 Oct 2021 04:04:10 -0400 Received: from verein.lst.de ([213.95.11.211]:36271 "EHLO verein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234753AbhJKIEC (ORCPT ); Mon, 11 Oct 2021 04:04:02 -0400 Received: by verein.lst.de (Postfix, from userid 2407) id CF92A68AFE; Mon, 11 Oct 2021 10:01:35 +0200 (CEST) Date: Mon, 11 Oct 2021 10:01:35 +0200 From: Christoph Hellwig To: Simon Ser Cc: Christoph Hellwig , Alex Deucher , Stephen Rothwell , Linux Kernel Mailing List , Linux Next Mailing List , Daniel Vetter , Benson Leung , Enric Balletbo i Serra , Greg Kroah-Hartman Subject: Re: linux-next: build failure after merge of the amdgpu tree Message-ID: <20211011080135.GA11242@lst.de> References: <20211008113116.4bdd7b6c@canb.auug.org.au> <_POw9ikafXoqSFqiOb8SZb_uvRZ4okgD4qrl4EtJ0UBiQTV7pwV3pJIM20eIzmpuFWDeBF9NPD00r72ttX0mZZ0bNeH_J44MoaB-jfjrQSU=@emersion.fr> <20211011073348.GA10672@lst.de> <-6WWj2RSqFheia8o3VKtAiF3bELME9376cYzwiLSY1-E7p9nqfWNqJ5i86Q--BKXa3aolokj8g8nj2tQorzn0LXuD85tD_rXSfE5t1lsvBs=@emersion.fr> <20211011074316.GA10882@lst.de> <20211011075125.GA11098@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Oct 11, 2021 at 07:57:17AM +0000, Simon Ser wrote: > No, we can't have a "I_AM_NOT_BROKEN" ioctl for each and every uAPI mis-use. > User-space detection has been determined to be the best course of action. If your API addition breaks userspace, yes you need an add-in. > I guess I'll just inline these functions in the driver then, if a revert will > be NACK'ed by you? It will be NACKed, and I will also complain to Linus about any PR containing buggy code like this. With your completely broken change you cement in a mapping of an executable name to map to what you consider a "bug" without any way to fix it up. Which is even worse for a something fast moving like chrome/chromeos which will eventually gets its act together and fix things while you'll keep a weird feature mismatch just for it around forever. No wonder our graphics stack is stuch a convoluted buggy mess if you keep piling broken workarounds over workarounds instead of sorting things out properly.