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;
Subject: Re: [RFC PATCH 0/8] Add configurable block device LED triggers
To:     Pavel Machek <pavel@ucw.cz>
Cc:     linux-block@vger.kernel.org, linux-leds@vger.kernel.org,
        axboe@kernel.dk, linux-kernel@vger.kernel.org,
        kernelnewbies@kernelnewbies.org
References: <20210729015344.3366750-1-arequipeno@gmail.com>
 <20210729085413.GA16945@amd>
From:   Ian Pilcher <arequipeno@gmail.com>
Message-ID: <b108799e-24a2-d5ec-e18e-b7ae8bded085@gmail.com>
Date:   Thu, 29 Jul 2021 12:03:04 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: <20210729085413.GA16945@amd>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Precedence: bulk

On 7/29/21 3:54 AM, Pavel Machek wrote:
> We normally have a trigger ("block device activity") which can then
> expose parameters ("I watch for read" and "I monitor sda1").
> 
> Is there a reason normal solution can not be used?

This big difference is that this allows different devices to drive
different LEDs.  For example, my NAS has 5 drive bays, each of which
has its own activity LED.  With these patches, I can create a
separate trigger for each of those LEDs and associate the drive in each
bay with the correct LED:

   sdb --> trigger1 --> LED1
    ⋮         ⋮         ⋮
   sdf --> trigger5 --> LED5

(sda is the SATA DOM boot drive.)

Note that this also supports associating multiple devices with a single
trigger, so it can be used for more complicated schemes.  For example,
if my NAS had an additional LED and an optical drive, I could do this:

   sr0 --+
         |
         +--> trigger0 --> LED0
         |
   sda --+

   sdb -----> trigger1 --> LED1
    ⋮         ⋮         ⋮
   sdf -----> trigger5 --> LED5

As far as I know, the current triggers (disk-activity, disk-read,
disk-write, and ide-disk) don't support this sort of arbitrary
device-trigger association.

This patch set also support triggering LEDs from pretty much any block
device (virtual as well as physical), not just ATA devices, although
that's just a matter of the place from which the trigger is "fired".

I hope this explains things.

Thanks!

-- 
========================================================================
                  In Soviet Russia, Google searches you!
========================================================================