[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <BYAPR04MB57493C2B95D0679C4B23BF8086220@BYAPR04MB5749.namprd04.prod.outlook.com>
Date: Sat, 4 Jan 2020 22:32:13 +0000
From: Chaitanya Kulkarni <Chaitanya.Kulkarni@....com>
To: "Singh, Balbir" <sblbir@...zon.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-block@...r.kernel.org" <linux-block@...r.kernel.org>,
"linux-nvme@...ts.infradead.org" <linux-nvme@...ts.infradead.org>
CC: "hch@....de" <hch@....de>,
"jejb@...ux.ibm.com" <jejb@...ux.ibm.com>,
"mst@...hat.com" <mst@...hat.com>,
"axboe@...nel.dk" <axboe@...nel.dk>,
"Sangaraju, Someswarudu" <ssomesh@...zon.com>
Subject: Re: [resend v1 1/5] block/genhd: Notify udev about capacity change
On 01/03/2020 08:44 PM, Singh, Balbir wrote:
>> >Since disk_set_capacity(() is on the same line as set_capacity()
>> >we should follow the same convention, which is :-
>> >
>> >1. Avoid exporting symbol.
>> >2. Mark new function in-line.
>> >
>> >Unless there is a very specific reason for breaking the pattern.
>> >
> I don't see the benefit of marking it as inline. I expect this code to be
> potentially expanded to provide callbacks into file system code for expansion
> (something you brought up), marking it as inline might be a limitation.
>
That can be done as a prep patch when framework is ready.
> I'd rather not clutter the headers with this code, but I am open to what the
> maintainers think as well.
>
Okay.
> Balbir Singh.
>
>
Powered by blists - more mailing lists