On 5/23/18 2:52 PM, Kees Cook wrote: > On Wed, May 23, 2018 at 7:31 AM, Jens Axboe <axboe@xxxxxxxxx> wrote: >> On 5/23/18 8:25 AM, Christoph Hellwig wrote: >>> On Wed, May 23, 2018 at 08:13:56AM -0600, Jens Axboe wrote: >>>>> Should I move to code to a new drivers/scsi/scsi_sense.c and add it to >>>>> drivers/scsi/Makefile as: >>>>> >>>>> obj-$(CONFIG_BLK_SCSI_REQUEST) += scsi_sense.o >>>>> >>>>> Every place I want to use the code is already covered by >>>>> CONFIG_BLK_SCSI_REQUEST, so it seems like I just need to know where to >>>>> put the .c file. :P >>>> >>>> I think this is so much saner than a SCSI select or dependency, so I'll >>>> have to disagree with Martin and Christoph. Just put it in drivers/scsi, >>>> if it's the location they care about. >>> >>> I actually plan to remove CONFIG_BLK_SCSI_REQUEST in a merge window >>> or two. The only users are scsi and the ide layer, (virtio_blk >>> support has already been accidentally disabled for a while), and getting >>> rid of it allows to to shrink and simply the scsi data structures. >>> >>> But if you want this for now lets keep scsi_sense.c in drivers/scsi >>> but depend on CONFIG_BLK_SCSI_REQUEST, that is easy enough to fix up. >> >> It could be a stand-alone dependency, doesn't have to be BLK_SCSI_REQUEST. >> BLA_SCSI_SENSE or something would do. I don't care too much about that, >> mostly getting rid of the entire stack dependency. > > Aaand, I can't do this and leave it in drivers/scsi because of drivers/Makefile: > > obj-$(CONFIG_SCSI) += scsi/ > > So: this needs to live in block/ just like CONFIG_BLK_SCSI_REQUEST's > scsi_ioctl.c. I will split it into CONFIG_BLK_SCSI_SENSE, but I'll > still need to move the code from drivers/scsi/ to block/. Is this > okay? Ugh, so that would necessitate a change there too. As I said before, I don't really care where it lives. I know the SCSI folks seem bothered by moving it, but in reality, it's not like this stuff will likely ever really change. Of the two choices (select entire SCSI stack, or just move this little bit), I know what I would consider the saner option... -- Jens Axboe
