Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Mon, 9 Jan 2023 19:05:14 +0100
From:   Pavel Machek <pavel@ucw.cz>
To:     Ian Pilcher <arequipeno@gmail.com>
Cc:     lee@kernel.org, linux-leds@vger.kernel.org,
        linux-kernel@vger.kernel.org, kabel@kernel.org
Subject: Re: [PATCH v13 1/2] docs: Add block device (blkdev) LED trigger
 documentation
Message-ID: <Y7xXWrR3jD3cUxWv@duo.ucw.cz>
References: <20221227225226.546489-1-arequipeno@gmail.com>
 <20221227225226.546489-2-arequipeno@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
        protocol="application/pgp-signature"; boundary="pTfp1MHXw0zAMTER"
Content-Disposition: inline
In-Reply-To: <20221227225226.546489-2-arequipeno@gmail.com>
Precedence: bulk


--pTfp1MHXw0zAMTER
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi!

This is the crazy interface I'm complaining about:

>   * /sys/class/leds/<led>/link_dev_by_path
>   * /sys/class/leds/<led>/unlink_dev_by_path
>   * /sys/class/leds/<led>/unlink_dev_by_name
>   * /sys/class/leds/<led>/linked_devices

Echoing filenames into files (with symlink resolution) is quite
strange, is it? As is having two different unlink interfaces.

I believe we do have other places handling similar N:M configuration
problems, so this should be similar to some of them.

Obvious improvement would be having only "link_dev_by_name" and
"unlink_dev_by_name", but then, unlink should really be rm.

Best regards,
								Pavel
--=20
People of Russia, stop Putin before his war on Ukraine escalates.

--pTfp1MHXw0zAMTER
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iF0EABECAB0WIQRPfPO7r0eAhk010v0w5/Bqldv68gUCY7xXWgAKCRAw5/Bqldv6
8pVvAJ0flK8MI/FofLXmIrMV1cmW6/qFgQCeKQh+kE0AF57LI1iY2SJ4Wjh7IbM=
=oY/d
-----END PGP SIGNATURE-----

--pTfp1MHXw0zAMTER--