On Mon, Jun 28, 2021 at 04:57:33PM +0200, Martin Wilck wrote: > Hello Christoph, > > On Mo, 2021-06-28 at 11:53 +0200, Christoph Hellwig wrote: > > On Mon, Jun 28, 2021 at 11:52:08AM +0200, mwilck@xxxxxxxx wrote: > > > From: Martin Wilck <mwilck@xxxxxxxx> > > > > > > This makes it possible to use scsi_result_to_blk_status() from > > > code that shouldn't depend on scsi_mod (e.g. device mapper). > > > > This really has no business being used outside of low-level SCSI > > code. > > And this is where my patch set uses it. Can you recommend a better > way how to access this algorithm, without making dm_mod.ko or dm- > mpath.ko depend on scsi_mod.ko, and without open-coding it > independently in a different code path? > The sg_io-on-multipath code needs to answer the question "is this a > path or a target error?". Therefore it calls blk_path_error(), which > requires obtaining a blk_status_t first. But that's not available in > the sg_io code path. So how should I deal with this situation? Not by exporting random crap from the SCSI code.
