"Jason A. Donenfeld" writes:
> I guess what I have in mind is the answer to these being "yes":
> - "Is it very common to be asleep for only 2 seconds before being woken?"
> - "Is it very common to be awake for only 2 seconds before sleeping?"
>
> I think it'd be easiest to have a knob somewhere
Hi Jon,
On Fri, Jul 01, 2022 at 02:22:38PM -0600, Jonathan Corbet wrote:
> So please forgive the noise from the peanut gallery
Yuh oh, I sure hope this isn't newsworthy for LWN. This has already
consumed me for two days...
> myself wondering...do you really need a knob for this? The kernel
>
Hi John,
On Thu, Jun 30, 2022 at 10:12:30AM -0700, John Stultz wrote:
> Does this preference come out of the too-many-options-in-gpg
> antipattern? Or is there something else?
There are numerous presentations and threads galore on why WireGuard
doesn't do knobs. Not worth rehashing here; it's
On Thu, Jun 30, 2022 at 3:06 AM Jason A. Donenfeld wrote:
> On Wed, Jun 29, 2022 at 09:25:32PM -0700, Kalesh Singh wrote:
> > Two concerns John raised:
> > 1) Adding new ABI we need to maintain
> > 2) Having unclear config options
> >
> > Another idea, I think, is to add the Kconfig option as
Hi Kalesh,
On Wed, Jun 29, 2022 at 09:25:32PM -0700, Kalesh Singh wrote:
> On Wed, Jun 29, 2022 at 5:30 PM Jason A. Donenfeld wrote:
> >
> > Hey again,
> >
> > On Thu, Jun 30, 2022 at 2:24 AM Jason A. Donenfeld wrote:
> > > 1) Introduce a simple CONFIG_PM_CONTINUOUS_AUTOSLEEPING Kconfig thing
>
On Wed, Jun 29, 2022 at 5:30 PM Jason A. Donenfeld wrote:
>
> Hey again,
>
> On Thu, Jun 30, 2022 at 2:24 AM Jason A. Donenfeld wrote:
> > 1) Introduce a simple CONFIG_PM_CONTINUOUS_AUTOSLEEPING Kconfig thing
> >with lots of discouraging help text.
> >
> > 2) Go with the /sys/power tunable
On Wed, Jun 29, 2022 at 06:44:14PM -0700, Joe Perches wrote:
> On Thu, 2022-06-30 at 02:50 +0200, Jason A. Donenfeld wrote:
> > On Wed, Jun 29, 2022 at 05:36:57PM -0700, Joe Perches wrote:
> > > > > +static ssize_t pm_userspace_autosleeper_show(struct kobject *kobj,
> > > > > +
On Thu, 2022-06-30 at 02:50 +0200, Jason A. Donenfeld wrote:
> On Wed, Jun 29, 2022 at 05:36:57PM -0700, Joe Perches wrote:
> > > > +static ssize_t pm_userspace_autosleeper_show(struct kobject *kobj,
> > > > + struct kobj_attribute *attr, char *buf)
> > > > +{
> > > >
On Wed, Jun 29, 2022 at 05:36:57PM -0700, Joe Perches wrote:
> > > +static ssize_t pm_userspace_autosleeper_show(struct kobject *kobj,
> > > + struct kobj_attribute *attr, char *buf)
> > > +{
> > > + return sprintf(buf, "%d\n", pm_userspace_autosleeper_enabled);
On Wed, 2022-06-29 at 16:19 -0700, Kalesh Singh wrote:
> On Wed, Jun 29, 2022 at 4:02 PM Jason A. Donenfeld wrote:
> > On Wed, Jun 29, 2022 at 03:26:33PM -0700, Kalesh Singh wrote:
> > > Thanks for taking a look. I'm concerned holding the sys/power/state
> > > open would have unintentional side
Hey again,
On Thu, Jun 30, 2022 at 2:24 AM Jason A. Donenfeld wrote:
> 1) Introduce a simple CONFIG_PM_CONTINUOUS_AUTOSLEEPING Kconfig thing
>with lots of discouraging help text.
>
> 2) Go with the /sys/power tunable and bikeshed the naming of that a bit
>to get it to something that
Hi John,
On Wed, Jun 29, 2022 at 04:52:05PM -0700, John Stultz wrote:
> Jason: Thanks for raising this issue and sharing this patch to avoid
> breakage! I really appreciate it.
>
> My only concern with this change introducting a userspace knob set at
> runtime, vs a (hopefully more specific than
On Wed, Jun 29, 2022 at 4:02 PM Jason A. Donenfeld wrote:
>
> Hi Kalesh,
>
> On Wed, Jun 29, 2022 at 03:26:33PM -0700, Kalesh Singh wrote:
> > Thanks for taking a look. I'm concerned holding the sys/power/state
> > open would have unintentional side effects. Adding the
> >
On Wed, Jun 29, 2022 at 4:02 PM Jason A. Donenfeld wrote:
>
> Hi Kalesh,
>
> On Wed, Jun 29, 2022 at 03:26:33PM -0700, Kalesh Singh wrote:
> > Thanks for taking a look. I'm concerned holding the sys/power/state
> > open would have unintentional side effects. Adding the
> >
On Wed, Jun 29, 2022 at 07:30:35PM +0200, Jason A. Donenfeld wrote:
> Properly resolved by whom? It sounds like you're up for intentionally
> allowing a userspace regression, and also volunteering other people's
> time into fixing that regression? The way I understand the kernel
> development
On Wed, Jun 29, 2022 at 12:05:23PM -0700, Kalesh Singh wrote:
>
> Android no longer uses PM_AUTOSLEEP, is correct. libsuspend is
> also now deprecated. Android autosuspend is initiatiated from the
> userspace system suspend service [1].
Is anything still using CONFIG_PM_AUTOSLEEP? Is it perhaps
[ Note, I'm not on the Android team and my response has nothing to do with
my employer. I would say the same thing with my previous employer. ]
On Wed, 29 Jun 2022 18:45:43 +0200
Christoph Hellwig wrote:
> On Wed, Jun 29, 2022 at 06:38:09PM +0200, Jason A. Donenfeld wrote:
> > On the
On Wed, Jun 29, 2022 at 06:38:09PM +0200, Jason A. Donenfeld wrote:
> On the technical topic, an Android developer friend following this
> thread just pointed out to me that Android doesn't use PM_AUTOSLEEP and
> just has userspace causing suspend frequently. So by his rough
> estimation your
On Wed, Jun 29, 2022 at 09:34:44AM -0700, Paul E. McKenney wrote:
> So you are OK if your patch is accepted, and then CONFIG_ANDROID is
> re-introduced but used only for building kernels intended to run on
> Android systems?
I don't think that is a good config. In general you want APIs
to
On Wed, Jun 29, 2022 at 06:25:32PM +0200, Jason A. Donenfeld wrote:
> Anyway, instead of the slow drip of "facts" and ≤three sentence emails,
> can you just write up a paragraph that indicates this is safe to do (for
> both (1) and (2)) in your v+1?
Why would I care? If your config wakeups up so
On Wed, Jun 29, 2022 at 06:13:05PM +0200, Jason A. Donenfeld wrote:
> Good! It sounds like you're starting to develop opinions on the matter.
No, I provide facts. Look at both the definition of the symbol, and
various distribution kernel that enabled it and think hard if they run
on "Android"
On Wed, Jun 29, 2022 at 06:09:18PM +0200, Jason A. Donenfeld wrote:
> CONFIG_ANDROID is used here for a reason. As somebody suggested in
> another thread of which you were a participant, it acts as a proxy for
> "probably running on Android hardware",
No, it does not in any way.
Hi Kalesh,
On Wed, Jun 29, 2022 at 03:26:33PM -0700, Kalesh Singh wrote:
> Thanks for taking a look. I'm concerned holding the sys/power/state
> open would have unintentional side effects. Adding the
> /sys/power/userspace_autosuspender seems more appropriate. We don't
> have a use case for the
On Wed, Jun 29, 2022 at 1:47 PM Jason A. Donenfeld wrote:
>
> Hi Kalesh,
>
> On Wed, Jun 29, 2022 at 12:05:23PM -0700, Kalesh Singh wrote:
> > Thanks for raising this.
> >
> > Android no longer uses PM_AUTOSLEEP, is correct. libsuspend is
> > also now deprecated. Android autosuspend is
Hi Kalesh,
On Wed, Jun 29, 2022 at 12:05:23PM -0700, Kalesh Singh wrote:
> Thanks for raising this.
>
> Android no longer uses PM_AUTOSLEEP, is correct. libsuspend is
> also now deprecated. Android autosuspend is initiatiated from the
> userspace system suspend service [1].
>
> A runtime config
On Wed, Jun 29, 2022 at 07:34:58PM +0200, Jason A. Donenfeld wrote:
> On Wed, Jun 29, 2022 at 06:38:09PM +0200, Jason A. Donenfeld wrote:
> > On the technical topic, an Android developer friend following this
> > thread just pointed out to me that Android doesn't use PM_AUTOSLEEP and
> > just has
On Wed, Jun 29, 2022 at 07:19:36PM +0200, Greg Kroah-Hartman wrote:
> On Wed, Jun 29, 2022 at 07:10:43PM +0200, Jason A. Donenfeld wrote:
> > On Wed, Jun 29, 2022 at 07:00:25PM +0200, Greg Kroah-Hartman wrote:
[ . . . ]
> > That sounds like a false dichotomy. It's not about "fix Android" vs "fix
On Wed, Jun 29, 2022 at 07:35:45PM +0200, Christoph Hellwig wrote:
> On Wed, Jun 29, 2022 at 07:30:35PM +0200, Jason A. Donenfeld wrote:
> > Properly resolved by whom? It sounds like you're up for intentionally
> > allowing a userspace regression, and also volunteering other people's
> > time into
On Wed, Jun 29, 2022 at 06:38:09PM +0200, Jason A. Donenfeld wrote:
> On the technical topic, an Android developer friend following this
> thread just pointed out to me that Android doesn't use PM_AUTOSLEEP and
> just has userspace causing suspend frequently. So by his rough
> estimation your
On Wed, Jun 29, 2022 at 07:19:36PM +0200, Greg Kroah-Hartman wrote:
> I would be totally and completly amazed if there are any Android kernels
> in real devices in the world that are not at the very least, based on
> LTS releases. But maybe there is, this patch series isn't going to land
> until
On Wed, Jun 29, 2022 at 12:56:43PM -0400, Steven Rostedt wrote:
> > And it will also "break" anyone else doing frequent suspends from
> > userspace, as that behavior is still in no way related to
> > CONFIG_ANDROID.
>
> Should there then be a CONFIG_FREQUENT_SUSPENDS ?
That'd be fine by me. It
On Wed, Jun 29, 2022 at 07:10:43PM +0200, Jason A. Donenfeld wrote:
> On Wed, Jun 29, 2022 at 07:00:25PM +0200, Greg Kroah-Hartman wrote:
> > I think that by the time the next kernel release comes out, and
> > percolates to a real Android device, the years gone by will have caused
> > those who
On Wed, Jun 29, 2022 at 07:00:25PM +0200, Greg Kroah-Hartman wrote:
> I think that by the time the next kernel release comes out, and
> percolates to a real Android device, the years gone by will have caused
> those who care about this to fix it.
You assume that there aren't Android devices using
On Wed, Jun 29, 2022 at 06:45:48PM +0200, Jason A. Donenfeld wrote:
> On Wed, Jun 29, 2022 at 06:37:01PM +0200, Christoph Hellwig wrote:
> > be a policy set somewhere either in the kernel or fed into the kernel
> > by userspace. Then we can key it off that, and I suspect it is
> > probably going
On Wed, Jun 29, 2022 at 06:52:08PM +0200, Jason A. Donenfeld wrote:
> On Wed, Jun 29, 2022 at 6:45 PM Christoph Hellwig wrote:
> >
> > On Wed, Jun 29, 2022 at 06:38:09PM +0200, Jason A. Donenfeld wrote:
> > > On the technical topic, an Android developer friend following this
> > > thread just
On Wed, Jun 29, 2022 at 6:45 PM Christoph Hellwig wrote:
>
> On Wed, Jun 29, 2022 at 06:38:09PM +0200, Jason A. Donenfeld wrote:
> > On the technical topic, an Android developer friend following this
> > thread just pointed out to me that Android doesn't use PM_AUTOSLEEP and
> > just has
On Wed, Jun 29, 2022 at 06:37:01PM +0200, Christoph Hellwig wrote:
> be a policy set somewhere either in the kernel or fed into the kernel
> by userspace. Then we can key it off that, and I suspect it is
> probably going to be a runtime variable and not a config option.
Right, this would be a
On Wed, Jun 29, 2022 at 06:30:07PM +0200, Christoph Hellwig wrote:
> On Wed, Jun 29, 2022 at 06:25:32PM +0200, Jason A. Donenfeld wrote:
> > Anyway, instead of the slow drip of "facts" and ≤three sentence emails,
> > can you just write up a paragraph that indicates this is safe to do (for
> > both
On Wed, Jun 29, 2022 at 06:15:27PM +0200, Christoph Hellwig wrote:
> On Wed, Jun 29, 2022 at 06:13:05PM +0200, Jason A. Donenfeld wrote:
> > Good! It sounds like you're starting to develop opinions on the matter.
>
> No, I provide facts. Look at both the definition of the symbol, and
> various
On Wed, Jun 29, 2022 at 06:15:27PM +0200, Christoph Hellwig wrote:
> On Wed, Jun 29, 2022 at 06:13:05PM +0200, Jason A. Donenfeld wrote:
> > Good! It sounds like you're starting to develop opinions on the matter.
>
> No, I provide facts.
Lol.
> Look at both the definition of the symbol, and
>
On Wed, Jun 29, 2022 at 06:10:20PM +0200, Christoph Hellwig wrote:
> On Wed, Jun 29, 2022 at 06:09:18PM +0200, Jason A. Donenfeld wrote:
> > CONFIG_ANDROID is used here for a reason. As somebody suggested in
> > another thread of which you were a participant, it acts as a proxy for
> > "probably
Hi Christoph,
On Wed, Jun 29, 2022 at 05:01:02PM +0200, Christoph Hellwig wrote:
> diff --git a/drivers/char/random.c b/drivers/char/random.c
> index e3dd1dd3dd226..f35ad1a9dff3e 100644
> --- a/drivers/char/random.c
> +++ b/drivers/char/random.c
> @@ -755,8 +755,7 @@ static int
On Wed, Jun 29, 2022 at 05:01:02PM +0200, Christoph Hellwig wrote:
> The ANDROID config symbol is only used to guard the binder config
> symbol and to inject completely random config changes. Remove it
> as it is obviously a bad idea.
>
> Signed-off-by: Christoph Hellwig
And I got confirmation
On Wed, Jun 29, 2022 at 05:01:02PM +0200, Christoph Hellwig wrote:
> The ANDROID config symbol is only used to guard the binder config
> symbol and to inject completely random config changes. Remove it
> as it is obviously a bad idea.
Ick, rcu and random driver changes? That's not ok, I'll go
44 matches
Mail list logo
