lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Tue, 10 Aug 2021 08:35:08 +0200
From:   Greg KH <>
To:     Ian Pilcher <>
Cc:     Marek BehĂșn <>,,,,,,,,
Subject: Re: [RFC PATCH v2 00/10] Add configurable block device LED triggers

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:
> 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 :)


greg k-h

Powered by blists - more mailing lists