On Thu, Jul 11, 2019 at 04:07:27PM -0700, Brendan Higgins wrote: > On Wed, Jul 3, 2019 at 3:25 PM Luis Chamberlain <mcg...@kernel.org> wrote: > > > > On Wed, Jul 03, 2019 at 08:57:58PM +0200, Greg Kroah-Hartman wrote: > > > > But again, this is a separate problem. The one I am addressing, on > > behalf of Cristina, is a subspace, dedicated towards *hardware* > > functionality. > > Hmm...maybe this isn't what I am looking for then. I am interested in > the problem of figuring out what dependencies I need to select to turn > on a desired config symbol (which is obviously a separate issue),
It isn't directly. the problem statement is different, and for that I do recommend checking out the kconfig-sat effort. It only indirectly relates in that we already know our kconfig semantics need work, and I do think that the underlying problem in this thread slowly strives towards addressing kconfig semantics for modules, associating one main kconfig symbol with one module. I have no evidence for this though. But since there are users who can gain from it, I don't see any issues from embracing it. > and > I am interested in associating symbols with a config symbol and then > ensuring that symbol is exercised. Basically, I want a way to make > sure my tests actually get run without a human looking at them; I feel > like what you are working on might help with this latter issue, but I > am not 100% sure. It sounds like it is not your primary goal in any > case. Nope, this topic only ralates to yours in the semantics case. Luis
