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 <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > > > On Mon, Aug 09, 2021 at 06:50:44PM -0500, Ian Pilcher wrote: > > > On 8/9/21 5:43 PM, Marek Behún wrote: > > > > 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
