On Tue, 21 Apr 2020 11:58:31 +0200 Christian Borntraeger <borntraeger@xxxxxxxxxx> wrote: > 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. > I don't think non-eckd dasd drivers are really useful outside of z/VM guests, so keeping at least the disciplines modular would be good. Also, what about special purpose environments like the zfcp dumper? Would be good to be able to keep these small. How big is the dasd code in the end?
