From: Logan Gunthorpe <logang@deltatee.com>
To: Emil Velikov <emil.l.velikov@gmail.com>
Cc: Keith Busch <keith.busch@intel.com>,
Myron Stowe <myron.stowe@gmail.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Bjorn Helgaas <bhelgaas@google.com>,
Geert Uytterhoeven <geert+renesas@glider.be>,
Jonathan Corbet <corbet@lwn.net>,
"David S. Miller" <davem@davemloft.net>,
Andrew Morton <akpm@linux-foundation.org>,
Mauro Carvalho Chehab <mchehab@kernel.org>,
Guenter Roeck <linux@roeck-us.net>,
Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>,
Linus Walleij <linus.walleij@linaro.org>,
Ryusuke Konishi <konishi.ryusuke@lab.ntt.co.jp>,
Stefan Berger <stefanb@linux.vnet.ibm.com>,
Wei Zhang <wzhang@fb.com>,
Kurt Schwemmer <kurt.schwemmer@microsemi.com>,
Stephen Bates <stephen.bates@microsemi.com>,
Linux PCI <linux-pci@vger.kernel.org>,
linux-doc@vger.kernel.org, linux-nvme@lists.infradead.org,
"Linux-Kernel@Vger. Kernel. Org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/1] MicroSemi Switchtec management interface driver
Date: Thu, 2 Feb 2017 09:37:14 -0700 [thread overview]
Message-ID: <fd54d9a2-5613-29b0-35fe-3db3ecbcdd05@deltatee.com> (raw)
In-Reply-To: <CACvgo520=CXUHNwd75Er0zPCiEQVfOu0h=eeHNDQ-uQn66kAJA@mail.gmail.com>
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
next prev parent reply other threads:[~2017-02-02 16:37 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-31 17:03 [PATCH 0/1] DRAFT: New Microsemi PCI Switch Management Driver Logan Gunthorpe
2017-01-31 17:03 ` [PATCH 1/1] MicroSemi Switchtec management interface driver Logan Gunthorpe
2017-01-31 17:26 ` Greg Kroah-Hartman
2017-01-31 17:35 ` Logan Gunthorpe
2017-01-31 17:49 ` Jonathan Corbet
2017-01-31 18:32 ` Logan Gunthorpe
2017-01-31 18:57 ` Greg Kroah-Hartman
2017-01-31 19:04 ` Logan Gunthorpe
2017-01-31 17:27 ` Greg Kroah-Hartman
2017-01-31 18:21 ` kbuild test robot
2017-01-31 20:48 ` Emil Velikov
2017-01-31 23:13 ` Logan Gunthorpe
2017-02-01 12:10 ` Emil Velikov
2017-02-02 16:37 ` Logan Gunthorpe [this message]
2017-02-03 13:49 ` Emil Velikov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=fd54d9a2-5613-29b0-35fe-3db3ecbcdd05@deltatee.com \
--to=logang@deltatee.com \
--cc=akpm@linux-foundation.org \
--cc=bhelgaas@google.com \
--cc=corbet@lwn.net \
--cc=davem@davemloft.net \
--cc=emil.l.velikov@gmail.com \
--cc=geert+renesas@glider.be \
--cc=gregkh@linuxfoundation.org \
--cc=jarkko.sakkinen@linux.intel.com \
--cc=keith.busch@intel.com \
--cc=konishi.ryusuke@lab.ntt.co.jp \
--cc=kurt.schwemmer@microsemi.com \
--cc=linus.walleij@linaro.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=mchehab@kernel.org \
--cc=myron.stowe@gmail.com \
--cc=stefanb@linux.vnet.ibm.com \
--cc=stephen.bates@microsemi.com \
--cc=wzhang@fb.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®