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 858E5C433F5 for ; Mon, 17 Jan 2022 07:03:23 +0000 (UTC) Received: from localhost ([::1] helo=shelob.surriel.com) by shelob.surriel.com with esmtp (Exim 4.94.2) (envelope-from ) id 1n9M30-0008Kx-3I for kernelnewbies@archiver.kernel.org; Mon, 17 Jan 2022 02:03:22 -0500 Received: from mail-pl1-x62d.google.com ([2607:f8b0:4864:20::62d]) by shelob.surriel.com with esmtps (TLS1.2) tls TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1n9M1F-0006GX-BM for kernelnewbies@kernelnewbies.org; Mon, 17 Jan 2022 02:01:33 -0500 Received: by mail-pl1-x62d.google.com with SMTP id u11so15145741plh.13 for ; Sun, 16 Jan 2022 23:01:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:from:to:cc:subject:message-id:mail-followup-to:mime-version :content-disposition; bh=urSjqugZ0tlevnYGp6gQWdGt0e5ls6p3CUFN+ZnIZP4=; b=IkJUwTWO8Yv5zIbjKLfM/1yr08VC5Pn7qa/JvcPIKJxnVe3BxSwoGBr5nN9zWCD/8X VUMEPWLxrZv+Vre8VcCepymLRU9G2W0oaAHn7eHEXmkZBXZrlypT8ocSefgRBIrsHc7c 8HX4c8Aycknaen5S6FPJrqcG87Ci25JZDb8iIj5mOKXp7s3UnhtDEIFajigFt4mwoXRK k0k3Yak8I/JrAxpuExJ7FwC115x2bvefHAfoEYzjoI5W3LuP9LJ+RjrI6Rn097weP0eL udXGjMCOChKVW24eH0r3ZwsA+svzAc0DduzYzYutRA5xH/vY7qi+JkDSvnZUdOwGGWod OGAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id :mail-followup-to:mime-version:content-disposition; bh=urSjqugZ0tlevnYGp6gQWdGt0e5ls6p3CUFN+ZnIZP4=; b=P5lgwLvP8AIWrvdkF4v0841VjVFEoxJCUbV7jWNgKO0ooR9xz8EROwm3u/pz2HHSdc 15thVpcmOvjEm5L+/55MhVerwIJe3Wt/PG5EFqsz2Rbq0g7SbbXo/aayCJEVBZ0spmGe YC8ZtqXjRruINjJ9tJDq64H6yTWQJhmilyvtfncmS3yHF0JFXrJEoUHrNppJz+znI+n+ XW4saoEOQXuOUetICjTjKKSFogdDEKI4rtJWYEHSbrerxMqyKyWnDE6vBpCreETSsbfI Zn8TcJbjN21f/PuFCM6WHsx4jPkPcBE70NbHx0fz9nDWjC6UOt2Ii5MsWvAqx+I8nrJX dD2w== X-Gm-Message-State: AOAM533zjUSC3c6jrsZxx+CrvZlCXSVUs6J5nJPETNH029wfplLuIV98 OnhluL9oRDy9wOKTQ/ywie8Zi8k/0iX+coM3 X-Google-Smtp-Source: ABdhPJylMgPkz2rKc+hm8L1PBbow+YerLYb207B0NTK4/2nhqf3zdFTKi+w7k5GJNtDBLCMH9QqidQ== X-Received: by 2002:a17:90a:f015:: with SMTP id bt21mr23616791pjb.3.1642402890329; Sun, 16 Jan 2022 23:01:30 -0800 (PST) Received: from mail.google.com (122-58-164-114-fibre.sparkbb.co.nz. [122.58.164.114]) by smtp.gmail.com with ESMTPSA id p1sm10774851pgj.46.2022.01.16.23.01.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 16 Jan 2022 23:01:29 -0800 (PST) Date: Mon, 17 Jan 2022 20:01:25 +1300 From: Paulo Miguel Almeida To: kernelnewbies@kernelnewbies.org Subject: ioctl number change / backwards compatibility doubt Message-ID: <20220117070125.GA17186@mail.google.com> Mail-Followup-To: Paulo Miguel Almeida , kernelnewbies@kernelnewbies.org MIME-Version: 1.0 Content-Disposition: inline Cc: paulo.miguel.almeida.rodenas@gmail.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=archiver.kernel.org@kernelnewbies.org 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 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) 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? 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? Best regards, Paulo Almeida _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies