Re: [PATCH 1/1] block, bfq: delete "bfq" prefix from cgroup filenames

[Ulf Hansson]

On Mon, 8 Apr 2019 at 17:05, Jens Axboe <axboe@xxxxxxxxx> wrote:
>
> On 4/8/19 9:04 AM, Johannes Thumshirn wrote:
> > [+Cc Michal ]
> > On Mon, Apr 08, 2019 at 04:54:39PM +0200, Paolo Valente wrote:
> >>
> >>
> >>> Il giorno 8 apr 2019, alle ore 16:49, Johannes Thumshirn <jthumshirn@xxxxxxx> ha scritto:
> >>>
> >>> On Mon, Apr 08, 2019 at 04:39:35PM +0200, Paolo Valente wrote:
> >>>> From: Angelo Ruocco <angeloruocco90@xxxxxxxxx>
> >>>>
> >>>> When bfq was merged into mainline, there were two I/O schedulers that
> >>>> implemented the proportional-share policy: bfq for blk-mq and cfq for
> >>>> legacy blk. bfq's interface files in the blkio/io controller have the
> >>>> same names as cfq. But the cgroups interface doesn't allow two
> >>>> entities to use the same name for their files, so for bfq we had to
> >>>> prepend the "bfq" prefix to each of its files. However no legacy code
> >>>> uses these modified file names. This naming also causes confusion, as,
> >>>> e.g., in [1].
> >>>>
> >>>> Now cfq has gone with legacy blk, so there is no need any longer for
> >>>> these prefixes in (the never used) bfq names. In view of this fact, this
> >>>> commit removes these prefixes, thereby enabling legacy code to truly
> >>>> use the proportional share policy in blk-mq.
> >>>>
> >>>> [1] https://github.com/systemd/systemd/issues/7057
> >>>
> >>> Hmm, but isn't this a user-space facing interface and thus some sort of ABI?
> >>> Do you know what's using it and what breaks due to this conversion?
> >>>
> >>
> >> Yep, but AFAIK, the problem is exactly the opposite: nobody uses these
> >> names for the proportional-share policy, or wants to use these names.  I'm
> >> CCing Lennart too, in case he has some improbable news on this.
> >>
> >> So the idea is to align names to what people expect, possibly before
> >> more confusion arises.
> >
> > OK, crazy idea, not sure if Jens and Tejun will beat me for this, but
> > symlinks?
> >
> > This way we can a) keep the old files and b) have them point to the new (a.k.a
> > cfq style) files.
>
> I did consider that, and that would be doable. But honestly, I'm having a
> hard time seeing what issue we are attempting to fix by doing this.

Jens, didn't we actually break userspace ABI when dropping the legacy
block code and its I/O schedulers?

So, to me, it seems like introducing symlinks as suggested above,
would actually fix this "regression", wouldn't it?

Kind regards
Uffe