On 4/29/21 1:33 PM, Martin Wilck wrote: > On Thu, 2021-04-29 at 09:20 -0700, Bart Van Assche wrote: >> On 4/29/21 8:50 AM, mwilck@xxxxxxxx wrote: >>> This makes it possible to use scsi_result_to_blk_status() from >>> code that shouldn't depend on scsi_mod (e.g. device mapper). >> >> I think that's the wrong reason to make a function inline. Please >> consider moving scsi_result_to_blk_status() into one of the block >> layer >> source code files that already deals with SG I/O, e.g. >> block/scsi_ioctl.c. > > scsi_ioctl.c, are you certain? scsi_result_to_blk_status() is an > important part of the block/scsi interface... You're right that that > this function is not a prime candidate for inlining, but I'm still > wondering where it belongs if we don't. The block/scsi_ioctl.c file is included in the kernel if and only if BLK_SCSI_REQUEST is enabled. And that Kconfig symbol only selects the block/scsi_ioctl.c file. Additionally, the following occurs in the SCSI Kconfig file: config SCSI tristate "SCSI device support" [ ... ] select BLK_SCSI_REQUEST In other words, block/scsi_ioctl.c is built unconditionally if SCSI is enabled. Adding the scsi_result_to_blk_status() function to the block/scsi_ioctl.c file would increase the size of kernels that enable bsg, ide, the SCSI target code or nfsd but not the SCSI initiator code. If the latter is a concern, how about moving scsi_result_to_blk_status() into a new file in the block directory? Thanks, Bart. -- dm-devel mailing list dm-devel@xxxxxxxxxx https://listman.redhat.com/mailman/listinfo/dm-devel
