Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753558AbbEEXvx (ORCPT ); Tue, 5 May 2015 19:51:53 -0400 Received: from mail-wg0-f47.google.com ([74.125.82.47]:36024 "EHLO mail-wg0-f47.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750764AbbEEXvv (ORCPT ); Tue, 5 May 2015 19:51:51 -0400 MIME-Version: 1.0 In-Reply-To: References: <1524218.bZcVRu7XR6@vostro.rjw.lan> Date: Wed, 6 May 2015 01:51:49 +0200 X-Google-Sender-Auth: wLcuNRAEuFI9gWljd8C_Ma3I4Sg Message-ID: Subject: Re: A desktop environment[1] kernel wishlist From: "Rafael J. Wysocki" To: David Lang Cc: "Rafael J. Wysocki" , Chirantan Ekbote , Alan Stern , John Stultz , Olof Johansson , Bastien Nocera , Linux Kernel Mailing List , snanda@chromium.org, Tomeu Vizoso , Linux PM list Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2710 Lines: 62 On Wed, May 6, 2015 at 1:38 AM, David Lang wrote: > On Wed, 6 May 2015, Rafael J. Wysocki wrote: > >>> You are, of course, correct. Ultimately the only requirement we have >>> is that there exists a way for userspace to determine if the system >>> woke up because of a user-triggered event. The actual mechanism by >>> which this determination is made isn't something I feel strongly >>> about. The reason I had been focusing on exposing the actual wakeup >>> event to userspace is because classifying wakeup events as >>> user-triggered or not feels to me like a policy decision that should >>> be left to userspace. If the kernel maintainers are ok with doing >>> this work in the kernel instead and only exposing a binary yes/no bit >>> to userspace for user-triggered wakeups, that's perfectly fine because >>> it still meets our requirements. >> >> >> Well, please see the message I've just sent. >> >> All wakeup devices have a wakeup source object associated with them. In >> principle, we can expose a "priority" attribute from that for user space >> to >> set as it wants to. There may be two values of it, like "normal" and >> "high" >> for example. >> >> Then, what only remains is to introduce separate wakeup counts for the >> "high" >> priority and "normal" priority wakeup sources and teach the power manager >> to >> use them. >> >> That leaves no policy in the kernel, but it actually has a chance to work. > > > how about instead of setting two states and defining that one must be a > subset of the other you instead have the existing feed of events and then > allow software that cares to define additional feeds that take the current > feed and filter it. We allow bpf filters in the kernel, so use those to > filter what events the additional feed is going to receive. > > remember that the interesting numbers in CS are 0, 1, and many, not 2 :-) > > don't limit things to two feeds with one always being a subset of the other, > create a mechanism to allow an arbitrary number of feeds that can be > filtered in different ways In my example above "high" is not a subset of "normal". They are separate sets. Each of them is a subset of the set of all wakeup sources, but that's obvious. And yes, you can create more of them, but then you'll need an interface to manipulate them which will probably be overkill for the use case at hand. Do you envision a use case where more than two sets would be necessary? Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/