Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Wed, 11 Aug 2021 12:50:48 +0200
From:   Marek =?UTF-8?B?QmVow7pu?= <kabel@kernel.org>
To:     Christoph Hellwig <hch@lst.de>
Cc:     Ian Pilcher <arequipeno@gmail.com>,
        Greg KH <gregkh@linuxfoundation.org>, pali@kernel.org,
        linux-block@vger.kernel.org, linux-leds@vger.kernel.org,
        axboe@kernel.dk, pavel@ucw.cz, linux-kernel@vger.kernel.org,
        kernelnewbies@kernelnewbies.org
Subject: Re: [RFC PATCH v2 00/10] Add configurable block device LED triggers
Message-ID: <20210811125048.3bbcebdb@thinkpad>
In-Reply-To: <20210811062642.GA3119@lst.de>
References: <20210809033217.1113444-1-arequipeno@gmail.com>
        <20210809205633.4300bbea@thinkpad>
        <81c128a1-c1b8-0f1e-a77b-6704bade26c0@gmail.com>
        <20210810004331.0f0094a5@thinkpad>
        <7b5f3509-5bcd-388b-8d3b-4ea95a9483ad@gmail.com>
        <20210811062642.GA3119@lst.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Wed, 11 Aug 2021 08:26:42 +0200
Christoph Hellwig <hch@lst.de> wrote:

> On Mon, Aug 09, 2021 at 06:50:44PM -0500, Ian Pilcher wrote:
> > On 8/9/21 5:43 PM, Marek Beh=C3=BAn wrote: =20
> >> I confess that I am not very familiar with internal blkdev API. =20
> >
> > It's mainly a matter of symbol visibility.  See this thread from a few
> > months ago:
> >
> >   https://www.spinics.net/lists/linux-leds/msg18244.html
> >
> > Now ... my code currently lives in block/, so there isn't actually
> > anything technically preventing it from iterating through the block
> > devices.
> >
> > The reactions to Enzo's patch (which you can see in that thread) make me
> > think that anything that iterates through all block devices is likely to
> > be rejected, but maybe I'm reading too much into it. =20
>=20
> I think the main issue with this series is that it adds a shitload of
> code and a hook in the absolute I/O fastpath for fricking blinkenlights.
> I don't think it is even worth wasting time on something this ridiculous.

That's why I think we should do this the way the netdev trigger does.
Periodically reading block_device's stats, and if they are greater,
blink the LED.

Marek