linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Doug Ledford <dledford@redhat.com>
To: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>,
	Dennis Dalessandro <dennis.dalessandro@intel.com>
Cc: Mike Marciniszyn <mike.marciniszyn@intel.com>,
	linux-rdma@vger.kernel.org,
	Mitko Haralanov <mitko.haralanov@intel.com>,
	linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	Ira Weiny <ira.weiny@intel.com>
Subject: Re: [PATCH v2 3/5] IB/hfi1: Add ioctl() interface for user commands
Date: Thu, 12 May 2016 15:48:16 -0400	[thread overview]
Message-ID: <f96bfe93-6bcc-7d55-8f7a-1792d12d41d9@redhat.com> (raw)
In-Reply-To: <20160512194006.GA6364@obsidianresearch.com>

[-- Attachment #1: Type: text/plain, Size: 1717 bytes --]

On 05/12/2016 03:40 PM, Jason Gunthorpe wrote:
> On Thu, May 12, 2016 at 03:27:27PM -0400, Dennis Dalessandro wrote:
>>> I thought we agreed to get rid of this as well? It certainly does not
>>> belong here, and as a general rule, I don't think ioctls should be
>>> doing capable tests..
>>
>> Yeah. I left it in this patch set because this just "ports" our existing
>> code to ioctl(). The eprom stuff is completely removed in another patch set
>> that I posted shortly after this. It's at:
> 
> Adding code and then removing it in a later patch is not a best
> practice.. Just don't add it or define ioctl numbers at all..

Yeah, but then that changes the nature of the patchset.  It goes from
being "We ported the existing write API to ioctl API" to "We ported
existing write API to ioctl API and also changed the scope of the API in
the process", which is considered bad coding practice (one stand alone
change per commit).  It's pretty 6 of one, half dozen of the other if
you ask me.  A better solution would have been to remove the EEPROM
stuff from the write ioctl, then only port the remaining stuff.  That
would have avoided both coding issues, but I also understand how they
got here, which is they did the ioctl conversion before they knew they
were going to rip out the EEPROM code.  In any case, the best fix would
be to rebase the two series that are remaining and move any "rip out
things like eeprom support" patches to prior to the ioctl patches and
make it so that they rip out the write interface version of it instead,
and then squash a second copy of the ioctl removal into this patch.

-- 
Doug Ledford <dledford@redhat.com>
              GPG KeyID: 0E572FDD



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]

  reply	other threads:[~2016-05-12 19:48 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-12 17:18 [PATCH v2 0/5] IB/hfi1: Remove write() and use ioctl() for user access Dennis Dalessandro
2016-05-12 17:18 ` [PATCH v2 1/5] IB/hfi1: Export drivers user sw version via sysfs Dennis Dalessandro
2016-05-12 17:18 ` [PATCH v2 2/5] IB/hfi1: Remove unused user command Dennis Dalessandro
2016-05-12 17:18 ` [PATCH v2 3/5] IB/hfi1: Add ioctl() interface for user commands Dennis Dalessandro
2016-05-12 17:43   ` Jason Gunthorpe
2016-05-12 18:12     ` Hefty, Sean
2016-05-12 19:27     ` Dennis Dalessandro
2016-05-12 19:40       ` Jason Gunthorpe
2016-05-12 19:48         ` Doug Ledford [this message]
2016-05-12 21:28           ` Jason Gunthorpe
2016-05-13 14:33             ` Dennis Dalessandro
2016-05-13 20:54         ` ira.weiny
2016-05-12 17:18 ` [PATCH v2 4/5] IB/hfi1: Remove write(), use ioctl() for user cmds Dennis Dalessandro
2016-05-12 17:18 ` [PATCH v2 5/5] IB/hfi1: Add trace message in user IOCTL handling Dennis Dalessandro
2016-05-12 17:34 ` [PATCH v2 0/5] IB/hfi1: Remove write() and use ioctl() for user access Jason Gunthorpe
2016-05-12 19:07   ` Dennis Dalessandro
2016-05-12 19:25     ` Jason Gunthorpe
2016-05-12 19:53       ` Dennis Dalessandro
2016-05-12 20:31         ` Doug Ledford
2016-05-12 21:27         ` Jason Gunthorpe

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=f96bfe93-6bcc-7d55-8f7a-1792d12d41d9@redhat.com \
    --to=dledford@redhat.com \
    --cc=dennis.dalessandro@intel.com \
    --cc=ira.weiny@intel.com \
    --cc=jgunthorpe@obsidianresearch.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rdma@vger.kernel.org \
    --cc=mike.marciniszyn@intel.com \
    --cc=mitko.haralanov@intel.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;
as well as URLs for NNTP newsgroup(s).