From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-13.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,INCLUDES_CR_TRAILER,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_2 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1ACF3C4338F for ; Thu, 29 Jul 2021 12:00:01 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id EC44860720 for ; Thu, 29 Jul 2021 12:00:00 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234231AbhG2MAD (ORCPT ); Thu, 29 Jul 2021 08:00:03 -0400 Received: from mail.kernel.org ([198.145.29.99]:49880 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234610AbhG2MAD (ORCPT ); Thu, 29 Jul 2021 08:00:03 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id BCA4760F21; Thu, 29 Jul 2021 11:59:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1627560000; bh=dVlivW1G35KXO37f2DhxEdxNU8sqEfSwmTd1QUrB7vE=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=JxwqEzyYPYymuA8cRC/Zbn9293xfgv72Y/v8+W5+YllJsHUaHm+agVxifF87zv4PA Sy53L3qxsQQhlRuVFG+E6BpwdOW/ruhUAQ4RKG1eEsz8adfjh9Rzai6OsfgfWzs7Sh OW0jxVXq/dbHGVrSPIwx+Ia1cn/Ygc4XY7Spvpte0kqmcbw59/L/V85UT0lpJBu4An cNvD7MmOHns+xNk2fEIj/1fQEoKZESe0Ek67qwX3djur/c2QLaomNQqh/4JgIKII9/ fSjDPjBPMBT7ftwBi4RUhafe/er+7s4Qmfak9qrX65wpMd+aJ/TiEOP54iQahf+afx ufUOA8wUpCEnA== Date: Thu, 29 Jul 2021 13:59:55 +0200 From: Marek =?UTF-8?B?QmVow7pu?= To: Ian Pilcher 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 1/8] docs: Add block device LED trigger documentation Message-ID: <20210729135955.3e3f591c@thinkpad> In-Reply-To: <20210729015344.3366750-2-arequipeno@gmail.com> References: <20210729015344.3366750-1-arequipeno@gmail.com> <20210729015344.3366750-2-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-leds@vger.kernel.org Dear Ian, On Wed, 28 Jul 2021 20:53:37 -0500 Ian Pilcher wrote: > * Document the sysfs attributes (/sys/class/block/led_trigger_* > and /sys/class/block/${DEV}/led_trigger) that can be used to > create, list, and delete block device LED triggers and to > set and clear device/trigger associations. > > * Pull API documentation from block/blk-ledtrig.c (once it > exists). > > Signed-off-by: Ian Pilcher thank you for this proposal. I don't really see the purpose for having multiple different block device LED triggers. Moreover we really do not want userspace to be able to add LED triggers with arbitrary names, and as many as the userspace wants. There is no sense in making userspace be able to create 10000 triggers. Also if userspace can create triggers with arbitrary names, it could "steal" a name for a real trigger. For example if netdev trigger is compiled as a module, and before loading someone creates blockdev trigger with name "netdev", the loading of netdev trigger will fail. I would like the blkdev trigger to work in a similar way the netdev trigger works: - only one trigger, with name "blkdev" - when activated on a LED, new sysfs files will be created: * device_name, where user can write sda1, vdb, ... * read (binary value, 1 means blink on read) * write (binary value, 1 means blink on write) * interval (blink interval) Note that device_name could allow multiple names, in theory... Also some other disk states may be included, like error, or something - also the blinking itself can be done as is done netdev trigger: every 50ms the work function would look at blkdev stats, and if current stat (number of bytes read/written) is different from previous, then blink the LED Marek From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-10.3 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,INCLUDES_CR_TRAILER,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_2 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E5115C4338F for ; Sat, 31 Jul 2021 19:31:41 +0000 (UTC) Received: from shelob.surriel.com (shelob.surriel.com [96.67.55.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 9F49560E97 for ; Sat, 31 Jul 2021 19:31:41 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 9F49560E97 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kernelnewbies.org Received: from localhost ([::1] helo=shelob.surriel.com) by shelob.surriel.com with esmtp (Exim 4.94.2) (envelope-from ) id 1m9uOE-0004gJ-5p; Sat, 31 Jul 2021 15:11:18 -0400 Received: from mail.kernel.org ([198.145.29.99]) by shelob.surriel.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1m94hl-0005dw-Io for kernelnewbies@kernelnewbies.org; Thu, 29 Jul 2021 08:00:01 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id BCA4760F21; Thu, 29 Jul 2021 11:59:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1627560000; bh=dVlivW1G35KXO37f2DhxEdxNU8sqEfSwmTd1QUrB7vE=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=JxwqEzyYPYymuA8cRC/Zbn9293xfgv72Y/v8+W5+YllJsHUaHm+agVxifF87zv4PA Sy53L3qxsQQhlRuVFG+E6BpwdOW/ruhUAQ4RKG1eEsz8adfjh9Rzai6OsfgfWzs7Sh OW0jxVXq/dbHGVrSPIwx+Ia1cn/Ygc4XY7Spvpte0kqmcbw59/L/V85UT0lpJBu4An cNvD7MmOHns+xNk2fEIj/1fQEoKZESe0Ek67qwX3djur/c2QLaomNQqh/4JgIKII9/ fSjDPjBPMBT7ftwBi4RUhafe/er+7s4Qmfak9qrX65wpMd+aJ/TiEOP54iQahf+afx ufUOA8wUpCEnA== Date: Thu, 29 Jul 2021 13:59:55 +0200 From: Marek =?UTF-8?B?QmVow7pu?= To: Ian Pilcher Subject: Re: [RFC PATCH 1/8] docs: Add block device LED trigger documentation Message-ID: <20210729135955.3e3f591c@thinkpad> In-Reply-To: <20210729015344.3366750-2-arequipeno@gmail.com> References: <20210729015344.3366750-1-arequipeno@gmail.com> <20210729015344.3366750-2-arequipeno@gmail.com> X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 X-Mailman-Approved-At: Sat, 31 Jul 2021 15:11:12 -0400 Cc: axboe@kernel.dk, kernelnewbies@kernelnewbies.org, linux-kernel@vger.kernel.org, linux-block@vger.kernel.org, pavel@ucw.cz, linux-leds@vger.kernel.org X-BeenThere: kernelnewbies@kernelnewbies.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Learn about the Linux kernel List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: kernelnewbies-bounces@kernelnewbies.org Dear Ian, On Wed, 28 Jul 2021 20:53:37 -0500 Ian Pilcher wrote: > * Document the sysfs attributes (/sys/class/block/led_trigger_* > and /sys/class/block/${DEV}/led_trigger) that can be used to > create, list, and delete block device LED triggers and to > set and clear device/trigger associations. > > * Pull API documentation from block/blk-ledtrig.c (once it > exists). > > Signed-off-by: Ian Pilcher thank you for this proposal. I don't really see the purpose for having multiple different block device LED triggers. Moreover we really do not want userspace to be able to add LED triggers with arbitrary names, and as many as the userspace wants. There is no sense in making userspace be able to create 10000 triggers. Also if userspace can create triggers with arbitrary names, it could "steal" a name for a real trigger. For example if netdev trigger is compiled as a module, and before loading someone creates blockdev trigger with name "netdev", the loading of netdev trigger will fail. I would like the blkdev trigger to work in a similar way the netdev trigger works: - only one trigger, with name "blkdev" - when activated on a LED, new sysfs files will be created: * device_name, where user can write sda1, vdb, ... * read (binary value, 1 means blink on read) * write (binary value, 1 means blink on write) * interval (blink interval) Note that device_name could allow multiple names, in theory... Also some other disk states may be included, like error, or something - also the blinking itself can be done as is done netdev trigger: every 50ms the work function would look at blkdev stats, and if current stat (number of bytes read/written) is different from previous, then blink the LED Marek _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies