[LSF/MM ATTEND] plan to deprecate old .request_fn request-based code path?

[Mike Snitzer <snitzer@redhat.com>]

Hi,

I'd like to attend LSF/MM and as the subject covers I'd like to at least
participate in a discussion about plans (realistic or not) for
removing/deprecating the old .request_fn path in block core and block
drivers.

The request-based DM code (only used for multipath) has gotten more
complex to support both old .request_fn and blk-mq (and stacking
combinations: .request_fn ontop of blk-mq paths, blk-mq ontop of
.request_fn paths).  Simplifying DM core in this area would be nice.

One of the hurdles has been blk-mq doesn't yet have a scheduler.  I know
Jens had/has something in the works.  But there is also the question of
whether DM's top-level blk-mq request_queue should be trained to
leverage/stack underlying blk-mq request_queue capabilities (Keith Busch
was going to look at this aspect in the context of multipath on NVMe but
I never heard anything from Keith on that).  As of now DM multipath's
blk-mq request_queue only supports a single (virtual) hw queue.

In addition to the above topic, I'd be open to discussing Linux MD
maintainership options with others if for some reason that is still an
unresolved situation come mid April.

Thanks,
Mike