Marek -
Thanks for taking the time to review this.
On 10/5/21 16:27, Marek Behún wrote:
first, as I replied in one of the previous versions: it is not customary
to use the const keyword in Linux the way you do use it, i.e.
int f(const int var)
Your argument was that this makes the code more safe when changes are
made in the future. Maybe this is true (although in my opinion it is
not), but since this isn't done anywhere in kernel AFAIK, please drop it
in this proposal.
I can do this.
Second, I really would like to solve the problem looking up the block
device, given name. Since block API does not provide such function, I
think we should try to add it. It does not make sense to not be able to
set, for example "sda1" to trigger a LED, when /sys/class/block/sda1
exists, but someone deleted the /dev/sda1 device file.
I agree with you (and Greg) that this would be preferable, and if
someone were to implement such an API I would happily use it.
However, having looked at fs/block_dev.c and fs/inode.c, I can say with
confidence that I don't have the knowledge of how the inode cache works
that would be needed to implement such an API properly . More
importantly, I have the definite impression that the block subsystem
maintainers would not be receptive to the idea.
Anyway, see other comments below:
A few explanatory responses below. Any points that aren't mentioned
below are changes that I will go ahead and make.
+/* Delayed work to periodically check for activity & blink LEDs */
+static DECLARE_DELAYED_WORK(led_bdev_work, led_bdev_process);
+/* How often to run the delayed work - in jiffies */
+static unsigned int led_bdev_interval;
This is wrong. The interval can't be same for all triggers, this does
not make sense. I want to be able to set different intervals for
different LEDs, as in netdev trigger. Sure maybe not many people will
use it, but the possibility should be there.
I think that it's different, rather than wrong, but I believe that I
can change the interval to a per-LED setting, rather than global.
The work will then also be per LED and your structures should become
more simple. You won't need to have NxM mapping between LEDs and block
devices.
I have feeling that per-LED work items are likely to cause contention
for the mutex, since they will probably all have the same (default)
interval and they will usually be set up at about the same time (i.e.
at system boot). Instead, I would propose to have a single work item
that is simply scheduled for the next time work is "needed" and then
checks all LEDs that are due at that time.
I also don't see that this would eliminate the many-to-many mapping. It
seems like a useful feature. For example, one could have a bunch of
device-specific read activity LEDs and a shared write (or discard) LED.
+ led->index = led_bdev_next_index++;
This variable led_bdev_next_index never gets subtracted from, it only
increases. So if I enable and disable blkdev trigger ULONG_MAX times,
I won't be able to enable it anymore since you return -EOVERFLOW ?
This doesn't make any sense.
Each trig_bdev and trig_led needs a unique index so that it can be added
to one or more xarrays. The increment-only pattern (capped at
ULONG_MAX - 1) is an easy way to generate unique indices.
And yes, this does mean that you can only associate an LED or a block
device with the trigger about 4 billion times on a 32-bit platform. I
really can't think of a scenario in which that limitation would be an
issue.
>> + bdev = blkdev_get_by_path(path, mode, THIS_MODULE);
>
And this is what we should discuss with blk API people. I would really
like to find the block device by name as seen in /sys/class/block.
Right ... but how?
--
========================================================================
In Soviet Russia, Google searches you!
========================================================================
