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 2A65DC433EF for ; Sun, 23 Jan 2022 07:57:32 +0000 (UTC) Received: from localhost ([::1] helo=shelob.surriel.com) by shelob.surriel.com with esmtp (Exim 4.94.2) (envelope-from ) id 1nBXkf-0007H6-G1 for kernelnewbies@archiver.kernel.org; Sun, 23 Jan 2022 02:57:29 -0500 Received: from mail-pj1-x102a.google.com ([2607:f8b0:4864:20::102a]) by shelob.surriel.com with esmtps (TLS1.2) tls TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1nBXiq-0005Hr-Ve for kernelnewbies@kernelnewbies.org; Sun, 23 Jan 2022 02:55:37 -0500 Received: by mail-pj1-x102a.google.com with SMTP id b1-20020a17090a990100b001b14bd47532so13323843pjp.0 for ; Sat, 22 Jan 2022 23:55:36 -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:references :mime-version:content-disposition:in-reply-to; bh=NJQ/GPn+VIo+AUUdu/jROAy2guHPh1F5Mp7HN6PqM7k=; b=F8zUaAfpLNg7yMl4qTgoR0PYF+I7QgQvphCl/j3vyAdb8tfoL6GX3rGCI+9wlZdCOp g4VgK6BKqxkrcIijRAU4XffthZ+gl3o/u3XntK0OUt7p2Q3PrQnnWJc2OY0tLgrla58N mBS3J7Ci+UYtAHVwR3pSqWqdcDB759JPArw567Z+YPMHvYaXE+D2N+x4r1CevaGC/YRd puge2jafxQyJ23KESyNPjyuFhrDngRsQlFuEC5TCQvMrhEHrOxhwT4DScjj0EjZQuD6L vJPU6QVAIeHkpPI0nJwFWebZylDvBA+qL7BnFwwiiJ+3xByLjRg8oi0R4wOMRr5Bh4hC xkJg== 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:references:mime-version:content-disposition :in-reply-to; bh=NJQ/GPn+VIo+AUUdu/jROAy2guHPh1F5Mp7HN6PqM7k=; b=bP0gDL0enFmDqiKp/i/5Lf0w8IShZt+VaaRxEeWK5afcfW8H5BC6Ke8/UC+4CM1jrX V5C5o4iUvvF8fWgp0A1bvdnza2nZha2sWDPesycqW7S9eNanbH5ixGgEaHfn2pylBnlJ ZhTSFJhPPZwd3QSpxMaiX7qrH2YbJLipGEEq9PlhTRYSS/lQz7dBUplqJGPbMjhntKl0 V3vj2d3+noC0pRj6EPr9uFzlFq7UqqjpngFd+W4WJKwRhdEb8RI/voG9INLA3pZUR3ZV eyuh7uONQdFRkGqZhm1XpNIznrRasK8FVwycTxaipLs8daalJHy4HBPYefQZsMbbEfN0 fvHQ== X-Gm-Message-State: AOAM532DGRPpF3Fnc/NJZovoThRmCwhdygKIYygfUmPSu53eXGjqaHFa 3Zc8D6L88giydpab4xzpWEk= X-Google-Smtp-Source: ABdhPJzy5ia3hdDzzqHibGH3UJDjTiuhlJvKH3vYSLN7a7f9uz3Gjjs98NYmPpHzVzwst21nimkYog== X-Received: by 2002:a17:902:6b87:b0:149:7d3c:124d with SMTP id p7-20020a1709026b8700b001497d3c124dmr10171340plk.57.1642924535345; Sat, 22 Jan 2022 23:55:35 -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 mq15sm10006244pjb.8.2022.01.22.23.55.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 22 Jan 2022 23:55:34 -0800 (PST) Date: Sun, 23 Jan 2022 20:55:30 +1300 From: Paulo Miguel Almeida To: Greg KH Subject: Re: ioctl number change / backwards compatibility doubt Message-ID: <20220123075530.GB79751@mail.google.com> Mail-Followup-To: Paulo Miguel Almeida , Greg KH , kernelnewbies@kernelnewbies.org References: <20220117070125.GA17186@mail.google.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: Cc: kernelnewbies@kernelnewbies.org 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 On Mon, Jan 17, 2022 at 01:58:42PM +0100, Greg KH wrote: > 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. Noted > > 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. Apologies for the delay, I had emailed the original author and I was waiting for his reply before I could answer this. It turns out I haven't gotten an official answer from him yet. (I do understand that he might be busy) I googled a fair bit of time and I'm 99% confident that there isn't such userspace/lib tool so I guess this will have done the hard way :( > > 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. > Dan Carpenter suggested in one of patch reviews that we keep the ioctl for backwards compatibility but start a brand new sysfs implementation to encompass existing functionality to make it easier to add new features in future. I will wrap my head around it and send some RFC patches soon. thanks, Paulo Almeida _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies