linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stefan Haberland <sth@linux.ibm.com>
To: Christoph Hellwig <hch@lst.de>,
	Jan Hoeppner <hoeppner@linux.ibm.com>,
	Jens Axboe <axboe@kernel.dk>,
	Heiko Carstens <heiko.carstens@de.ibm.com>,
	Vasily Gorbik <gor@linux.ibm.com>,
	Christian Borntraeger <borntraeger@de.ibm.com>
Cc: linux-s390@vger.kernel.org, linux-block@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: stop using ioctl_by_bdev in the s390 DASD driver
Date: Tue, 21 Apr 2020 16:17:53 +0200	[thread overview]
Message-ID: <b4f38eb4-ab32-6713-fb8a-0c8e81efc645@linux.ibm.com> (raw)
In-Reply-To: <20200421061226.33731-1-hch@lst.de>

Hi Christoph,

thanks for addressing this. But I must say that I do not like this approach.
I get your point why you want this ioctl to be removed and I agree with
that.

Having those implicit partitions at all is really ugly but I fear that this
is widely used int the field. So I can not simply remove this code although
I would like to. Maybe we find a way to deprecate this.
But anyway...

Forcing the driver to be build in may have a lot of implications which we
should at least have a look at and maybe discuss with the distributors.
All major distributions have the driver build as modules and use module
parameters in the initrd for example.

The second thing is that I do not really like this s390-specific blockdevice
operation.

I can imagine some ways to get rid of this ioctl_by_bdev. Maybe having a
udev
rule to add a partition from userspace or having the driver add the implicit
partition at the end. Or maybe something else.

If it is OK I will have a look at this and discuss this issue with my
colleagues and come up with a different approach.

Regards,
Stefan



Am 21.04.20 um 08:12 schrieb Christoph Hellwig:
> Hi Jens and DASD maintainers,
>
> can you take a look at this series, which stops the DASD driver from
> issuing ioctls from kernel space, in preparation of removing
> ioctl_by_bdev.  I don't really like the new s390-only method, but short
> of forcing the dasd driver to be built into the kernel I can't think of
> anything better.  But maybe the s390 maintainers are fine with forcing
> the DASD driver to be built in, in which case we could go down that
> route?



  parent reply	other threads:[~2020-04-21 14:18 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-21  6:12 stop using ioctl_by_bdev in the s390 DASD driver Christoph Hellwig
2020-04-21  6:12 ` [PATCH 1/3] dasd: refactor dasd_ioctl_information Christoph Hellwig
2020-04-21  6:12 ` [PATCH 2/3] block: add a s390-only biodasdinfo method Christoph Hellwig
2020-04-21  6:12 ` [PATCH 3/3] partitions/ibm: stop using ioctl_by_bdev Christoph Hellwig
2020-04-21  9:58 ` stop using ioctl_by_bdev in the s390 DASD driver Christian Borntraeger
2020-04-21 10:32   ` Cornelia Huck
2020-04-21 10:43     ` Christian Borntraeger
2020-04-21 10:53       ` Christoph Hellwig
2020-04-21 14:17 ` Stefan Haberland [this message]
2020-04-21 15:03   ` Christoph Hellwig

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=b4f38eb4-ab32-6713-fb8a-0c8e81efc645@linux.ibm.com \
    --to=sth@linux.ibm.com \
    --cc=axboe@kernel.dk \
    --cc=borntraeger@de.ibm.com \
    --cc=gor@linux.ibm.com \
    --cc=hch@lst.de \
    --cc=heiko.carstens@de.ibm.com \
    --cc=hoeppner@linux.ibm.com \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    /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).