Seeking help addressing maintainer objections

* Seeking help addressing maintainer objections
@ 2024-04-02 15:59 Ian Pilcher
  2024-04-03 11:38 ` Bjørn Mork
  0 siblings, 1 reply; 4+ messages in thread
From: Ian Pilcher @ 2024-04-02 15:59 UTC (permalink / raw)
  To: kernelnewbies

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/ledtrig-blkdev.c
[2] 
https://github.com/ipilcher/ledtrig-blkdev/blob/pre-6.9/Documentation/leds/ledtrig-blkdev.rst
[3] 
https://lore.kernel.org/lkml/a7ff3338-3d5e-4402-aaba-16e740f4ed5b@gmail.com/T/#mbcf916e3582ae237a08390f5405822bd85f02c89

-- 
========================================================================
If your user interface is intuitive in retrospect ... it isn't intuitive
========================================================================

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

^ permalink raw reply	[flat|nested] 4+ messages in thread