All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@kernel.dk>
To: Christoph Hellwig <hch@lst.de>
Cc: Ilya Dryomov <idryomov@gmail.com>, Song Liu <song@kernel.org>,
	Miquel Raynal <miquel.raynal@bootlin.com>,
	Richard Weinberger <richard@nod.at>,
	Vignesh Raghavendra <vigneshr@ti.com>,
	Stefan Haberland <sth@linux.ibm.com>,
	Jan Hoeppner <hoeppner@linux.ibm.com>,
	linux-block@vger.kernel.org, ceph-devel@vger.kernel.org,
	linux-bcache@vger.kernel.org, linux-raid@vger.kernel.org,
	linux-mtd@lists.infradead.org, linux-s390@vger.kernel.org
Subject: Re: [PATCH 02/11] mtip32xx: return -ENOTTY for all unhanled ioctls
Date: Sun, 1 Nov 2020 09:45:21 -0700	[thread overview]
Message-ID: <842f4d23-b8c2-8ade-caf3-50b7cb9542cb@kernel.dk> (raw)
In-Reply-To: <20201101102735.GA26447@lst.de>

On 11/1/20 3:27 AM, Christoph Hellwig wrote:
> On Sat, Oct 31, 2020 at 08:58:52AM -0600, Jens Axboe wrote:
>> On 10/31/20 2:58 AM, Christoph Hellwig wrote:
>>> -ENOTTY is the convention for "driver does not support this ioctl".
>>> Use it properly in mtip32xx instead of the bogys -EINVAL.
>>
>> While that's certainly true, there is a risk in making a change like this
>> years after the fact. Not that I expect there are any mtip32xx users
>> left at this point, but...
> 
> -ENOTTY is what most drivers return.  That being said we can keep the
> old behavior, so if you prepfer that I can respin to do that.

Yeah I know that -ENOTTY is what they all should use (and most of course
does), just saying that this change carries some risk. Given that
mtip32xx can probably be retired in the not-too-distant future, I say we
just keep the -EINVAL here.

-- 
Jens Axboe


WARNING: multiple messages have this Message-ID (diff)
From: Jens Axboe <axboe@kernel.dk>
To: Christoph Hellwig <hch@lst.de>
Cc: linux-raid@vger.kernel.org, Jan Hoeppner <hoeppner@linux.ibm.com>,
	Vignesh Raghavendra <vigneshr@ti.com>,
	linux-s390@vger.kernel.org, Richard Weinberger <richard@nod.at>,
	linux-block@vger.kernel.org, Song Liu <song@kernel.org>,
	linux-bcache@vger.kernel.org, linux-mtd@lists.infradead.org,
	Stefan Haberland <sth@linux.ibm.com>,
	Miquel Raynal <miquel.raynal@bootlin.com>,
	Ilya Dryomov <idryomov@gmail.com>,
	ceph-devel@vger.kernel.org
Subject: Re: [PATCH 02/11] mtip32xx: return -ENOTTY for all unhanled ioctls
Date: Sun, 1 Nov 2020 09:45:21 -0700	[thread overview]
Message-ID: <842f4d23-b8c2-8ade-caf3-50b7cb9542cb@kernel.dk> (raw)
In-Reply-To: <20201101102735.GA26447@lst.de>

On 11/1/20 3:27 AM, Christoph Hellwig wrote:
> On Sat, Oct 31, 2020 at 08:58:52AM -0600, Jens Axboe wrote:
>> On 10/31/20 2:58 AM, Christoph Hellwig wrote:
>>> -ENOTTY is the convention for "driver does not support this ioctl".
>>> Use it properly in mtip32xx instead of the bogys -EINVAL.
>>
>> While that's certainly true, there is a risk in making a change like this
>> years after the fact. Not that I expect there are any mtip32xx users
>> left at this point, but...
> 
> -ENOTTY is what most drivers return.  That being said we can keep the
> old behavior, so if you prepfer that I can respin to do that.

Yeah I know that -ENOTTY is what they all should use (and most of course
does), just saying that this change carries some risk. Given that
mtip32xx can probably be retired in the not-too-distant future, I say we
just keep the -EINVAL here.

-- 
Jens Axboe


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

  reply	other threads:[~2020-11-01 16:45 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-31  8:57 block ioctl cleanups Christoph Hellwig
2020-10-31  8:57 ` Christoph Hellwig
2020-10-31  8:58 ` [PATCH 01/11] mtd_blkdevs: don't override BLKFLSBUF Christoph Hellwig
2020-10-31  8:58   ` Christoph Hellwig
2020-10-31 21:32   ` Richard Weinberger
2020-10-31 21:32     ` Richard Weinberger
2020-10-31 23:11   ` antlists
2020-10-31 23:11     ` antlists
2020-10-31  8:58 ` [PATCH 02/11] mtip32xx: return -ENOTTY for all unhanled ioctls Christoph Hellwig
2020-10-31  8:58   ` Christoph Hellwig
2020-10-31 14:58   ` Jens Axboe
2020-10-31 14:58     ` Jens Axboe
2020-11-01 10:27     ` Christoph Hellwig
2020-11-01 10:27       ` Christoph Hellwig
2020-11-01 16:45       ` Jens Axboe [this message]
2020-11-01 16:45         ` Jens Axboe
2020-10-31  8:58 ` [PATCH 03/11] block: don't call into the driver for BLKFLSBUF Christoph Hellwig
2020-10-31  8:58   ` Christoph Hellwig
2020-10-31  8:58 ` [PATCH 04/11] block: add a new set_read_only method Christoph Hellwig
2020-10-31  8:58   ` Christoph Hellwig
2020-10-31  8:58 ` [PATCH 05/11] rbd: implement ->set_read_only to hook into BLKROSET processing Christoph Hellwig
2020-10-31  8:58   ` Christoph Hellwig
2020-11-02 11:30   ` Ilya Dryomov
2020-11-02 11:30     ` Ilya Dryomov
2020-10-31  8:58 ` [PATCH 06/11] md: " Christoph Hellwig
2020-10-31  8:58   ` Christoph Hellwig
2020-11-03  0:19   ` James Troup
2020-11-03  0:19     ` James Troup
2020-11-03  9:32     ` Christoph Hellwig
2020-11-03  9:32       ` Christoph Hellwig
2020-10-31  8:58 ` [PATCH 07/11] dasd: " Christoph Hellwig
2020-10-31  8:58   ` Christoph Hellwig
2020-10-31  8:58 ` [PATCH 08/11] block: don't call into the driver for BLKROSET Christoph Hellwig
2020-10-31  8:58   ` Christoph Hellwig
2020-10-31  8:58 ` [PATCH 09/11] loop: use set_disk_ro Christoph Hellwig
2020-10-31  8:58   ` Christoph Hellwig
2020-10-31  8:58 ` [PATCH 10/11] block: remove set_device_ro Christoph Hellwig
2020-10-31  8:58   ` Christoph Hellwig
2020-10-31  8:58 ` [PATCH 11/11] block: remove __blkdev_driver_ioctl Christoph Hellwig
2020-10-31  8:58   ` Christoph Hellwig
2020-11-01 16:46 ` block ioctl cleanups Jens Axboe
2020-11-01 16:46   ` Jens Axboe

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=842f4d23-b8c2-8ade-caf3-50b7cb9542cb@kernel.dk \
    --to=axboe@kernel.dk \
    --cc=ceph-devel@vger.kernel.org \
    --cc=hch@lst.de \
    --cc=hoeppner@linux.ibm.com \
    --cc=idryomov@gmail.com \
    --cc=linux-bcache@vger.kernel.org \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=linux-raid@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=miquel.raynal@bootlin.com \
    --cc=richard@nod.at \
    --cc=song@kernel.org \
    --cc=sth@linux.ibm.com \
    --cc=vigneshr@ti.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.