On Tue, Aug 10, 2021 at 03:38:40PM +0200, Marek Behún wrote:

On Tue, 10 Aug 2021 08:35:08 +0200
Greg KH [off-list ref] wrote:

quoted

On Mon, Aug 09, 2021 at 06:50:44PM -0500, Ian Pilcher wrote:

quoted

On 8/9/21 5:43 PM, Marek Behún wrote:  

quoted

I confess that I am not very familiar with internal blkdev API.  

It's mainly a matter of symbol visibility.  See this thread from a few
months ago:

  https://www.spinics.net/lists/linux-leds/msg18244.html

Now ... my code currently lives in block/, so there isn't actually
anything technically preventing it from iterating through the block
devices.

The reactions to Enzo's patch (which you can see in that thread) make me
think that anything that iterates through all block devices is likely to
be rejected, but maybe I'm reading too much into it.


Greg / Christoph -

(As you were the people who expressed disapproval of Enzo's patch to
export block_class and disk_type ...)

Can you weigh in on the acceptability of iterating through the block
devices (searching by name) from LED trigger code within the block
subsystem (i.e. no new symbols would need to be exported)?

This would allow the trigger to implement the sysfs API that Marek and
Pavel want.  

No idea, let's see the change first, we can never promise anything :)

Hi Greg,

Can't we use blkdev_get_by_path() (or blk_lookup_devt() with
blkdev_get_by_dev())?
This would open the block device and return a struct block_device *.
When the LED trigger is disabled, it would also have to release the
device.

But what about when the device is removed from the system first?  Be
careful about that...

Anyway, sure, try those functions, I really do not know, all I
originally complained about was those exports which did not need to be
exported.

thanks,

greg k-h

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