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  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:   Fri, 8 Nov 2019 11:39:17 +0100
From:   Greg Kroah-Hartman <>
To:     Georgi Djakov <>
Cc:     Linux PM list <>,
        "" <>,
        Viresh Kumar <>,
        Bjorn Andersson <>
Subject: Re: [GIT PULL] interconnect changes for 5.5

On Thu, Nov 07, 2019 at 05:42:13PM +0200, Georgi Djakov wrote:
> Hi Greg,
> On 11/7/19 16:21, Greg Kroah-Hartman wrote:
> > On Thu, Nov 07, 2019 at 02:46:53PM +0200, Georgi Djakov wrote:
> >> Hi Greg,
> >>
> >> This is a pull request with interconnect patches for the 5.5 merge window.
> >> All patches have been for a while in linux-next without reported issues. The
> >> details are in the signed tag. Please consider pulling into char-misc-next.
> > 
> > I don't know about
> > 0003-interconnect-Disallow-interconnect-core-to-be-built-.patch here.
> > Shouldn't you just fix up the dependancies of subsystems that rely on
> > this?  We are moving more and more to kernels that "just work" with
> > everything as modules, even on arm64 systems.  So forbiding the
> > interconnect code from being able to be built as a module does not feel
> > good to me at all.
> Thank you for commenting on this! The initial idea was to keep everything as
> modular as possible. The reasons behind this change is that other core
> frameworks like cpufreq (and possibly others) want to call the interconnect
> APIs. Some of these frameworks are built-in only and it would be easier to
> handle dependencies if interconnect core built-in too. Now each user that
> can be built-in has to specify in Kconfig that it depends on INTERCONNECT ||

That's fine, when those subsystems start to use those apis, that
dependency needs to be added.  Nothing new here, and you forcing it to
either be "on or off" isn't going to change that.  Let's do it correctly


greg k-h

Powered by blists - more mailing lists