Received: by 2002:a05:6a10:c604:0:0:0:0 with SMTP id y4csp2918967pxt; Mon, 9 Aug 2021 11:59:54 -0700 (PDT) X-Google-Smtp-Source: ABdhPJznaeOl/euG6HwUCRlbTKrsJmhadTqF4hsssnUvl+HMfqRTQ1DDFzYWuu2XMhjP0/7YixLg X-Received: by 2002:a92:bf12:: with SMTP id z18mr148941ilh.274.1628535594388; Mon, 09 Aug 2021 11:59:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1628535594; cv=none; d=google.com; s=arc-20160816; b=WcTs1CxFVx12qXNtTgg3usM2PzWblJ31IsXfsJJqUzYIzWn43Y8r33R9rxvNtCPpe6 qAm2r1KYllX2YdVHBzf/vhWttfO90h/oOwc1WdrCL8BuUECeyKvCHsVwiRD1HKwQviqe v1gXGBCp5SktmZ8u/dxbb7bdGCROp7hD+71UE5LQRLjaZtC2u5OjpjbngqCdrxEykgaD spponVA9YsfTWAzEDjxOmUYkoJ+Fo/UYUcy6jdoTbRuJ1fTauREhBhoqFY/Wi3F+Qric 1GTMY6PM6v02vCChrtERh9xYISa09q9nopX4nw4OhqKrjs/LMWLYtO9ngdLwY7XsktYL 0ZYw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :dkim-signature; bh=ifr839w6zRqD0iVYQ3+kU3n5yX0xnRbES52h/ARd2bg=; b=Kr7vKTQCNBfW1t1Rj8O3DcYC7sfwTytCVvrLkymDu5iNA1sIo/6SibscmQsrdBK/uL I/ALQ2I046i+50Ei/7V7JjcRzaPGdZweaaZe0ZcqnBJCE0PP9sXc7kU/tROatWh5VcOK sCS/ai3csZPy8iO4rBiSRCX/Dev81w/vs3N/GRU6CqEbE9czUoYCrBWnKuJ4WAB7v5Me XjnDSQiv/DF3VYTw9h9t8DO+sdMUhIrcrloyGwg/7kUkEoAWvMktandswWk2LgjiQRiy lisl3WY7t7KfI2n+hbfMdEOoqFmFE8KJvfYMfF7RSyCwRNIqE12izpyAWVK4nw0jQUwS 6/IQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=ANWNU9Tm; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id q17si19237537ilj.42.2021.08.09.11.59.42; Mon, 09 Aug 2021 11:59:54 -0700 (PDT) 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; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=ANWNU9Tm; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235760AbhHIS5L (ORCPT + 99 others); Mon, 9 Aug 2021 14:57:11 -0400 Received: from mail.kernel.org ([198.145.29.99]:37168 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235656AbhHIS5J (ORCPT ); Mon, 9 Aug 2021 14:57:09 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 862FB60F11; Mon, 9 Aug 2021 18:56:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1628535408; bh=Club1rpvylBf8gX0nH4hqgxX2CQBVQEJTP5FNvLKgAk=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=ANWNU9Tm1mKTkj9B/l+QFWhzd7r/JBDVhmaDmwjWAHIfKqdJAN/jzm1orZCfZP5Wl t0OdJAU3y+ZCBGkiYl5lnLnC160AZGO+lWsZEhHjg2B0M+tZNQG9YPH1oKLA+dfqq7 y9Fu45aXst02HJVczZl2JshcolbV1AIGDoEtKLlcRD4YVj7Y8P/GVO9gKhxJXWJbTM NAKlzpgG3xxZsv6Qxk+bpusM+j8o1L2+y0b/UvNmGsr57+dnKodlo1/ztipg7iZ6EL peGna2Dl7YW2cdd+fSqDh+d5Xn9pc8kPYRrGtAikq4nbS2m78IihhCF770eCs72jgI SKq3tFfNBmhdA== Date: Mon, 9 Aug 2021 20:56:33 +0200 From: Marek =?UTF-8?B?QmVow7pu?= To: Ian Pilcher , pali@kernel.org Cc: 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: <20210809205633.4300bbea@thinkpad> In-Reply-To: <20210809033217.1113444-1-arequipeno@gmail.com> References: <20210809033217.1113444-1-arequipeno@gmail.com> X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello Ian, thank you for your proposal. Some comments below: On Sun, 8 Aug 2021 22:32:07 -0500 Ian Pilcher wrote: > One thing that has not changed is that associations between block > devices and LEDs are still set via an attribute on the device, rather > than the LED. This is much simpler, as the device attribute only has > to handle a single value (the name of the associated LED), rather than > potentially handling multiple device names. It may be simpler, but it is in contrast to how the netdev trigger works, which already is in upstream for many years. I really think we should try to have similar sysfs ABIs here. (I understand that the netdev trigger is currently unable to handle multiple network interfaces - but it is possible to extend it so.) > I have modeled the interface for the /sys/block//led > attribute on the sysfs interface used for selecting a trigger. All > available LEDs (all LEDs associated with the blkdev trigger) are > shown when the attribute is read, with the currently selected LED > enclosed in square brackets ([]). I think it is reasonable to be able to set something like this: led0 : blink on activity on any of [sda, sdb, sdc] led1 : blink on activity on sda led2 : blink on activity on sdb led3 : blink on activity on sdc If I am reading your code correctly, it looks that only one LED can be configured for a block device. Is this true? If so, then the above configuration cannot be set. Also you are blinking the LED on any request to the block device. I would rather expect to be able to set the LED to blink on read and on write. (And possibly on other functions, like discard, or critical temperature, or error, ...) I would like to know what other people think about this. Marek