On Wed, 2021-04-28 at 15:54 -0400, Mike Snitzer wrote: > > Ngh... not loving this at all. I'm not surprised :-) I infer from your reply that you acknowledge this is something that should be done one way or the other, and I'm glad about that. > But here is a patch (that I didn't > compile test) that should be folded in, still have to think about how > this could be made cleaner in general though. Thanks, much appreciated. > Also, dm_sg_io_ioctl should probably be in dm-rq.c (maybe even dm- > mpath.c!?) > > From: Mike Snitzer <snitzer@xxxxxxxxxx> > Date: Wed, 28 Apr 2021 15:03:20 -0400 > Subject: [PATCH] dm: use scsi_result_to_blk_status rather than open- > coding it > > Other small cleanups/nits. > > BUT the fact that dm.c now #includes <scsi/scsi.h> and <scsi/sg.h> > leaves a very bitter taste. > > Also, hardcoding the issuing of a "fail_path" message (assumes tgt is > dm-mpath) but still having checks like !tgt->type->message.. its all > very contrived and awkward! This I can explain. I need to check t->type->message because not all targets define it. If I didn't, yet used message(), the kernel might crash. I would have avoided the hard-coded "fail_path", too, if I had found a way to figure out which messages a given target supports, or whether the target in question is the multipath target in the first place. But I couldn't figure it out. If it's possible, please tell me how. Wrt "fail_path", the assumption is that other rq-based targets would either not support "fail_path" and thus return an error, or implement it with the same semantics as multipath. In both cases, my patch would do the "right thing" (falling back to standard behavior in the error case). Thanks, Martin
