From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751794AbdBBQh3 (ORCPT ); Thu, 2 Feb 2017 11:37:29 -0500 Received: from ale.deltatee.com ([207.54.116.67]:36065 "EHLO ale.deltatee.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750879AbdBBQh0 (ORCPT ); Thu, 2 Feb 2017 11:37:26 -0500 To: Emil Velikov References: <1485882204-26947-1-git-send-email-logang@deltatee.com> <1485882204-26947-2-git-send-email-logang@deltatee.com> <35aab5e1-c86d-efbb-f0c8-288469aeb52f@deltatee.com> Cc: Keith Busch , Myron Stowe , Greg Kroah-Hartman , Bjorn Helgaas , Geert Uytterhoeven , Jonathan Corbet , "David S. Miller" , Andrew Morton , Mauro Carvalho Chehab , Guenter Roeck , Jarkko Sakkinen , Linus Walleij , Ryusuke Konishi , Stefan Berger , Wei Zhang , Kurt Schwemmer , Stephen Bates , Linux PCI , linux-doc@vger.kernel.org, linux-nvme@lists.infradead.org, "Linux-Kernel@Vger. Kernel. Org" From: Logan Gunthorpe Message-ID: Date: Thu, 2 Feb 2017 09:37:14 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 172.16.1.111 X-SA-Exim-Rcpt-To: linux-kernel@vger.kernel.org, linux-nvme@lists.infradead.org, linux-doc@vger.kernel.org, linux-pci@vger.kernel.org, stephen.bates@microsemi.com, kurt.schwemmer@microsemi.com, wzhang@fb.com, stefanb@linux.vnet.ibm.com, konishi.ryusuke@lab.ntt.co.jp, linus.walleij@linaro.org, jarkko.sakkinen@linux.intel.com, linux@roeck-us.net, mchehab@kernel.org, akpm@linux-foundation.org, davem@davemloft.net, corbet@lwn.net, geert+renesas@glider.be, bhelgaas@google.com, gregkh@linuxfoundation.org, myron.stowe@gmail.com, keith.busch@intel.com, emil.l.velikov@gmail.com X-SA-Exim-Mail-From: logang@deltatee.com Subject: Re: [PATCH 1/1] MicroSemi Switchtec management interface driver X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on ale.deltatee.com) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 01/02/17 05:10 AM, Emil Velikov wrote: > You can keep it roughly as-is if you're ~reasonably certain one won't > change it in the future. I've made the change anyway. I think it's better now. > Some teams frown upon adding new IOCTL(s) where existing ones can be > made backward/forward compatible. > I'm not fully aware of the general direction/consensus on the topic, > so it might be a minority. Sure, I just don't know what might be needed in the future so it's hard to add a version or flags ioctl now. > On the other hand, reading through sysfs for module version in order > to use IOCTL A or B sounds quite hacky. Do you have an example where > this is used or pointed out as good approach ? I don't know of anything doing it that way now. But it sure would be easy and make a bit of sense. (We'd actually use the module version for something useful.) Either way, it would really depend on if and how things change in the future. The point is there are options to expand if needed. > Afaict the idea is to not ship/bundle/release userspace until kernel > parts are in. > The "do not commit the changes" is implied as [very rarely] distros > package from "random" git checkouts. Leading to all sorts of fun when > it is mismatched wrt the kernel parts. Likelihood of doing that here > is virtually none here, so this is a JFYI inspired by some past > experiences. Understood. > Glad to hear. Then again you already had most of the things nicely done, imho. Great, thanks. Logan