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 shelob.surriel.com (shelob.surriel.com [96.67.55.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 25D78C433FE for ; Mon, 17 Jan 2022 12:59:25 +0000 (UTC) Received: from localhost ([::1] helo=shelob.surriel.com) by shelob.surriel.com with esmtp (Exim 4.94.2) (envelope-from ) id 1n9Rb0-00052A-52; Mon, 17 Jan 2022 07:58:50 -0500 Received: from out5-smtp.messagingengine.com ([66.111.4.29]) by shelob.surriel.com with esmtps (TLS1.2) tls TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1n9Ray-00051q-34 for kernelnewbies@kernelnewbies.org; Mon, 17 Jan 2022 07:58:49 -0500 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 45CDA5C0C10; Mon, 17 Jan 2022 07:58:45 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Mon, 17 Jan 2022 07:58:45 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kroah.com; h= date:from:to:subject:message-id:references:mime-version :content-type:in-reply-to; s=fm2; bh=xxnNiGSQY61gtvBriB2wc9+u4P5 BpwI8BWTAgELa5vs=; b=bKziQ+QL3N0yJ0J/S2FDBoVhPf22KtFYzYbL1TFY7/Z LvqVw1sgNeTgJpZZccnECOjpyGUa7J5xIjpGxeK1RQQSlnTZXEsgae/WW4nrJFQF q+6CNJolUWztBkOi2gqAXObHj+rMMu1INlHDiUxbCNezeyqa+O0zcuRL4lKv0a6Y RmEPNlio4RFa6D+A8bw7OMP7B7YwA+QLEPOuuOmzR02imeQ5p/ylr8UN5ykqpZxZ Pf3WV7SEV3YQ7hflktoMC+l4H2Bsyo/HsR4qv8EPn/2rPJxz+5urdwcKekteVQrc +gp9f8dUPqHotWMRIYDbsGIEo880z9OP9RwoWEXAKZg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=xxnNiG SQY61gtvBriB2wc9+u4P5BpwI8BWTAgELa5vs=; b=S+NVUiAEzKIIeOv8IlUZ2D mf98LL0G9BbGYwFblILER5w41YbDYlCr27nENsuhcok4gZ3sgZS3bg/XdePsaM5V jZINP3IQIfvjCTtezhKpdxBBxER3g2puEgVh03k/I7btY7yMUaD2n+2AJPAJ2KbS 0phsl6PeMXv4uXgYAfewXCRATvucvMCCMQT9KegF02ZpLRMXQZpRj+Sd8If+GsC8 HuaK4scL5X7iIBY+hi4IOCR6ja5s/PGyF9mmzflBSeQ/fMminZ8vhoMFW72z5r2S oonO+ChASNXob0jiu82cmkGHYF9kHNlqeewN6oTqbDOoVKXqMHrMIJTCpQxzCnVA == X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddruddugdegiecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepfffhvffukfhfgggtuggjsehttdertd dttddvnecuhfhrohhmpefirhgvghcumffjuceoghhrvghgsehkrhhorghhrdgtohhmqeen ucggtffrrghtthgvrhhnpeevueehjefgfffgiedvudekvdektdelleelgefhleejieeuge egveeuuddukedvteenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhl fhhrohhmpehgrhgvgheskhhrohgrhhdrtghomh X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 17 Jan 2022 07:58:44 -0500 (EST) Date: Mon, 17 Jan 2022 13:58:42 +0100 From: Greg KH To: Paulo Miguel Almeida , kernelnewbies@kernelnewbies.org Subject: Re: ioctl number change / backwards compatibility doubt Message-ID: References: <20220117070125.GA17186@mail.google.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20220117070125.GA17186@mail.google.com> X-BeenThere: kernelnewbies@kernelnewbies.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Learn about the Linux kernel List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: kernelnewbies-bounces@kernelnewbies.org On Mon, Jan 17, 2022 at 08:01:25PM +1300, Paulo Miguel Almeida wrote: > Hi everyone, > > Context: > > I've been working on a driver called pi433 in the staging area and it > basically exposes a char device so the user can read/write stuff to > it while obtaining tx/rx configuration via ioctl calls. > > Tx/Rx configurations are both structs that (ideally) would be exposed > to the userspace to let the developer to #include it on their code. > > Info that *might* be relevant about this driver: > > - This driver went straight to the staging area due to a few TODOs > listed by the original author. > - The ioctl Code and Seq numbers are conflicting with the ones listed > in the ioctl-numbers.rst Not many people ever look at that file, and it is ok to have conflicts as the same tool should never have to handle multiple drivers where a conflict happens. > Problem: > > I realized that one of the structs used to pass/retrieve info needs > to have some of its members changed (data type and etc) Great! > Questions: > > 1: Given the driver's history and ioctl number conflit, is the backwards > compatibility something to be kept or not to be taken into consideration > as ioctl numbering rules weren't followed? Try to find out who is using these ioctls. If you can change the userspace tool at the same time, all is fine. If not, then there can be problems. > 2: The original author lists on the TODO file of the driver that 'he is > afraid that using ioctl wasn't a good idea'. I pondered the alternatives > and, *in case I can get rid of ioctl*, sysfs || configfs could be used. Does > anyone suggests a different approach? Same answer as above, it depends on what userspace tool is using these ioctls. Also it depends on what they do. Many informational ioctls can just be replaced with sysfs files, and many configuration ioctls can be replaced with configfs, but for other things, sometimes you need an ioctl. So it depends. Try to get ahold of the userspace side and then you can usually work it out. thanks, greg k-h _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies