I have been maintaining an out of tree module for several years, and I'd like to take (yet another) run at getting it accepted. In order to do so, however, I need some advice/help to meet the requirements of the relevant subsystem maintainer. The module in question is an LED trigger for block devices. It allows the system administrator to create relationships between LEDS and block devices, so that activity (reads, writes, etc.) on those devices will cause the LEDs to blink. You can see the latest version (for 6.8 kernels) here[1]. The trigger is very configurable. It supports many-to-many relationships between block devices and LEDS, so a block device can be associated with more than one LED (potentially for different types of activity) and an LED can be associated with one or more block devices. These many-to-many relationships are part of the problem. LED triggers are traditionally configured with sysfs, and sysfs attributes don't really work all that well for configuring a list of things (such as the block devices associated with an LED). In order to avoid a read/modify/write cycle when adding or removing a device/LED association, and adhere to the one value per file guideline, the trigger provides write-only attributes for adding and removing associations. (Existing associations are represented as symbolic links.) The sysfs interface is documented here[2]. The maintainer of the LEDs subsystem considers this interface to be "crazy", but he has not suggested any alternative.[3] (I have not been able to find any existing example of configuring many-to-many relationships via sysfs.) The second problem is the use of device file paths (including symbolic link resolution), rather than kernel names, when creating associations. This limitation exists because the block subsystem does not provide an API to open a block device by its kernel name; only device file paths and device numbers (major & minor) are supported. Adding such an API to the block subsystem has been proposed many times over the years, and it has been denied (often vehemently) on every occasion. I believe it's accurate to say that the maintainers of the block subsystem feel that device file paths (and to a lesser extent device numbers) are *the* correct way to refer to block devices, and they are not willing to add APIs that use kernel names. Does anyone have any suggestions on how I can move forward with this? Thanks! [1] https://github.com/ipilcher/ledtrig-blkdev/blob/pre-6.9/drivers/leds/trigger... [2] https://github.com/ipilcher/ledtrig-blkdev/blob/pre-6.9/Documentation/leds/l... [3] https://lore.kernel.org/lkml/a7ff3338-3d5e-4402-aaba-16e740f4ed5b@gmail.com/... -- ======================================================================== If your user interface is intuitive in retrospect ... it isn't intuitive ========================================================================