[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <ZyO2g3Lh6rvDd8DP@slm.duckdns.org>
Date: Thu, 31 Oct 2024 06:55:31 -1000
From: Tejun Heo <tj@...nel.org>
To: Yu Kuai <yukuai1@...weicloud.com>
Cc: axboe@...nel.dk, josef@...icpanda.com, linux-block@...r.kernel.org,
linux-kernel@...r.kernel.org, cgroups@...r.kernel.org,
yi.zhang@...wei.com, yangerkun@...wei.com,
"yukuai (C)" <yukuai3@...wei.com>
Subject: Re: [PATCH v2 1/5] blk-cgroup: add a new helper blkg_print_dev_name()
Hello,
On Thu, Oct 31, 2024 at 04:04:00PM +0800, Yu Kuai wrote:
> > On Mon, Sep 30, 2024 at 04:52:58PM +0800, Yu Kuai wrote:
> > > +static inline bool blkg_print_dev_name(struct seq_file *sf,
> > > + struct blkcg_gq *blkg)
> > > +{
> > > + struct gendisk *disk = blkg->q->disk;
> > > +
> > > + if (!disk)
> > > + return false;
> > > +
> > > + seq_printf(sf, "%u:%u", disk->major, disk->first_minor);
> > > + return true;
> > > +}
> > > +
> >
> > I wonder whether we just should add a name field to disk.
>
> And suggestions on this set now? I guess add a name filed is not
> appropriate. :(
Yeah, I don't know. I've always struggled a bit with block device names. We
use MAJ:MIN in all the input interfaces and mix the disk names and MAJ:MIN
when outputting and there are (or is it used to be now?) request_queues
without disk attached, so sometimes names are just not available.
Jens, do you any preference here? The proposed patch can be fine but e.g. it
can race against disk_release() if the caller isn't careful and it also
sucks not knowing the name in destruction path.
Thanks.
--
tejun
Powered by blists - more mailing lists