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 04C82C433F5 for ; Wed, 16 Mar 2022 14:08:16 +0000 (UTC) Received: from localhost ([::1] helo=shelob.surriel.com) by shelob.surriel.com with esmtp (Exim 4.94.2) (envelope-from ) id 1nUUJd-0005ky-Q9; Wed, 16 Mar 2022 10:07:53 -0400 Received: from wout1-smtp.messagingengine.com ([64.147.123.24]) by shelob.surriel.com with esmtps (TLS1.2) tls TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1nUUJb-0005kU-1N for kernelnewbies@kernelnewbies.org; Wed, 16 Mar 2022 10:07:51 -0400 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id 2287C3200F81; Wed, 16 Mar 2022 10:07:46 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Wed, 16 Mar 2022 10:07:46 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kroah.com; h=cc :content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to; s=fm1; bh=+qbi3xMctebUbEX+7cQSX+ARfjOMmVLg6lR9WF HX0Io=; b=FOVdNzSkQjs60RLJH4aY6xZ0658CnlmOBjkRe/NEgVlQ7qikT9gOaN OBvdddzvSUGJM8EvS9vSy+OKZtcm2JaDI8wYR8J6Ke0HyJv3o5lJNnpUofIwm7b3 2E/rQLMYZbtQzmQpGsP9mLixvplWDjvtaYFzdWVsj5IHl+ZU+/mg8CDF2mdInskC 384OPlHW+zgN3w57tFy4SNcTKF+P2bfdfy1dfHkU4mIX/ngzsv+xYdrLKQo2FDQb lgkLpSFHkeEqmCm3bfgb4lCZhN1zJ9glK4eAKWbQEm+RyTYN7GBTzP3U3qht+mOz bnJNpaLM6bQ32dknrhgFuLItP/vb/Ecw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=+qbi3xMctebUbEX+7 cQSX+ARfjOMmVLg6lR9WFHX0Io=; b=PTXps/fz0mB/P0s1ynDaErJ4G5b0FYgOV jhotwnhPQQKO6uCLL9K1yeTAfjhG7GKW89X7kd1BM5iOFPq5mHIJyGwXFzZrWFxa EpjbLu68GlhX2UL+cBG7+hMx2XnuAsfB0+gJa3YduaRB4TQlF4M2ff9lo+LG9EU+ utfQ2nsw1bIhaNoJ0E7VYj9jDebAwmRNyewvNTgxKe9YaMWHu9CxMwKh8gHKAqDe b3qrs34XigLKUwifrs77L9TzgiTT8oLp8AK/Nsjk4N7vZxT37jpFqT9/zJwgEWRf /LevKqeekT0TnfF8SWJpBeKa03TNN6OxvPE73RKTzvjgQQ+H+8gaw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrudefvddgheekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkfhggtggujgesthdtre dttddtvdenucfhrhhomhepifhrvghgucfmjfcuoehgrhgvgheskhhrohgrhhdrtghomheq necuggftrfgrthhtvghrnhepveeuheejgfffgfeivddukedvkedtleelleeghfeljeeiue eggeevueduudekvdetnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghi lhhfrhhomhepghhrvghgsehkrhhorghhrdgtohhm X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 16 Mar 2022 10:07:44 -0400 (EDT) Date: Wed, 16 Mar 2022 15:07:40 +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> <20220123075530.GB79751@mail.google.com> <20220124044906.GA8954@mail.google.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: 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 Sat, Mar 12, 2022 at 01:05:46PM +1300, Paulo Miguel Almeida wrote: > On Mon, Jan 24, 2022 at 07:20:45AM +0100, Greg KH wrote: > > On Mon, Jan 24, 2022 at 05:49:06PM +1300, Paulo Miguel Almeida wrote: > > > On Sun, Jan 23, 2022 at 12:04:48PM +0100, Greg KH wrote: > > > > > > when you told me to look for the userspace tool that interfaced with the > > > ioctl, my interpretation was that you were referring to something akin > > > to what /usr/bin/uname utility is to the syscall uname. Please correct me > > > if I'm wrong. > > > > > > re: what calls the ioctl created by the driver. > > > > > > I'm led to believe that users of this driver make ioctl sycall > > > invocations directly from their application's source code like this: > > > > > > #include "pi433_if.h" /* userspace driver header */ > > > #include /* ioctl */ > > > > > > int file_desc = open("/dev/pi433.0", O_RDWR); > > > struct pi433_tx_cfg tx_cfg = { > > > .frequency = 433000000, > > > .bit_rate = 4800, > > > ... > > > }; > > > > > > int ret_val = ioctl(file_desc, PI433_IOC_WR_TX_CFG, tx_cfg); > > > .... > > > > Yes, sorry for the confusion, this is what I am referring to. Where is > > that userspace code as that is the code you will be needing to change if > > you want to change this ioctl interface. > > > > thanks, > > > > greg k-h > > Hi Greg, > > The original author replied my email with that question. He sent me > some the code used to interface with char device, however, the source > code he provided me is already incompatible with the current version of > the driver: > > #include "rfxx.h" (file header name has changed) > > int main(int argc, char *argv[]) > { > ... > struct rfxx_send_config sendConfig; (struct name has changed) > ... > fd = open("/dev/rf69_0.0", O_RDWR); *(char device name changed)* > ... > sendConfig.data_mode = packet; *(property doesn't exist)* > ... > (IOCTL call has a different name) > ret = ioctl(fd, RFXX_IOC_WR_SEND_CONFIG, &sendConfig); > if (ret == -1) > ... > } > > Assuming that I tweak these tools he provided me with and publish them, > will I then be able to tweak the structures passed back and forth via > ioctl? (do I need to change ioctl number in this case?) > > The reason why I'm asking this is because given the fact that other > developers could have written similar code for interfacing with the > driver (and that we will never know because code is proprietary), I > won't be sure that I've changed all occurences at the same time, right? > > All in all, please correct if there are gaps in this train of thought. > > - If a change doesn't break *compiled* code (such as struct renaming) > then it's 'okay' to make the change ? (this has happened in the this > driver before) For staging drivers, the user/kernel api usually needs to be changed, so yes, as long as you can change the tools that are being used to talk to this api, you should be fine. thanks, greg k-h _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies