[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <b7e4a728-1f58-f304-cb5b-1aa2206a6bb4@de.ibm.com>
Date: Tue, 21 Apr 2020 11:58:31 +0200
From: Christian Borntraeger <borntraeger@...ibm.com>
To: Christoph Hellwig <hch@....de>,
Stefan Haberland <sth@...ux.ibm.com>,
Jan Hoeppner <hoeppner@...ux.ibm.com>,
Jens Axboe <axboe@...nel.dk>,
Heiko Carstens <heiko.carstens@...ibm.com>,
Vasily Gorbik <gor@...ux.ibm.com>
Cc: linux-s390@...r.kernel.org, linux-block@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: stop using ioctl_by_bdev in the s390 DASD driver
On 21.04.20 08:12, Christoph Hellwig wrote:
> 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?
Hmm the defconfig results in dasd built-in anyway. But distros really like
to keep it modular.
Hmm, we do have
obj-$(CONFIG_DASD) += dasd_mod.o
obj-$(CONFIG_DASD_DIAG) += dasd_diag_mod.o
obj-$(CONFIG_DASD_ECKD) += dasd_eckd_mod.o
obj-$(CONFIG_DASD_FBA) += dasd_fba_mod.o
Would it work to make CONFIG_DASD built-in only and keep the other 3 as modules?
Not sure about the implications.
Powered by blists - more mailing lists