Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp906729ybi; Wed, 19 Jun 2019 09:51:54 -0700 (PDT) X-Google-Smtp-Source: APXvYqzbETM2mesqN2sz2Id94P/hUnC0AYKCEXDoTjvs8tVvtYqGV/q8Ee1A5d6ne8yf9G0hwnBM X-Received: by 2002:a63:d211:: with SMTP id a17mr8596673pgg.269.1560963113994; Wed, 19 Jun 2019 09:51:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1560963113; cv=none; d=google.com; s=arc-20160816; b=md02oeuZ9BhgPfThJH2bx8jP0HL8xaHKLeqQB4vVS5w+5ukT7pNzg7eGXBcd3VaxX+ Yn8BLR2OmdIzGT4FxQ5gTEC89ETvoKZNiFU13hIfZEB/HSgTNAdJVDrtM+N+CsYSu2hk 8nNwkcktf24KC3ffXDHlt0zqYRERMzCVCQ+nCIEpRA0A7ZFXeXMegfV+6VcyaRzQIUzf XYExYL4AjXZYm/BrrDiAqgdUVinIiwMLVJfI01U+zDd0lxXYz9InUekD8j6CZWfac/vP 5jlFJDX43XHXeKDrtL0oUIHHAecWflIA9ojTielq/JBeMnrVfUCfWjZ6ZK4LdlbW2Quo bxjA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=CSjfI0FdDG+opCSifX1YJn6xlbBS3iUU167wnFEoRhM=; b=YRtVitcdhb/FV1X/B/o0jvIZXy3PVUYPBTPb2aPfte9rBAr6Ioflil0zDg/yjI7FUf QsWFKfZPwI8rc79j7dFwnU24BJULGQz/7KV1ju2H9TUca/sNN607dQmkag/RIGBQFf7h ziRTWcsBYdYF0MObjpFL2ub7LkVYVqFYa7liY+SF2iu0E1EaD1SWtYeql+OJLmeLfJD2 wcMKrffjdyRsLzTK5FVUcxJ490CYr3Qm5Z0NQoCi11cSTPdeIcoDBAEel6/OUZ1c2Arg jUVpachhf+qFHCoGvFkPq14JHBKmQ+NCaU56a2Ie58aYCy5+xnV89cAU68+486l9SPkv me2Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@android.com header.s=20161025 header.b=na7Ua03U; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=android.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id a17si1866961pjs.98.2019.06.19.09.51.38; Wed, 19 Jun 2019 09:51:53 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@android.com header.s=20161025 header.b=na7Ua03U; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=android.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730135AbfFSQv2 (ORCPT + 99 others); Wed, 19 Jun 2019 12:51:28 -0400 Received: from mail-pl1-f195.google.com ([209.85.214.195]:37725 "EHLO mail-pl1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726109AbfFSQv2 (ORCPT ); Wed, 19 Jun 2019 12:51:28 -0400 Received: by mail-pl1-f195.google.com with SMTP id bh12so53366plb.4 for ; Wed, 19 Jun 2019 09:51:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=android.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=CSjfI0FdDG+opCSifX1YJn6xlbBS3iUU167wnFEoRhM=; b=na7Ua03UGckZdukIKV1RvIdd+/eBWPhu2Xv1M5Iz4VOhj/xZXPCeybNKDOwEFHQqaJ 4Qni8MMipPwexSAx6NTSD4WeH19YYHLHhPr6jeYGXnaX/3yDoaEUBIW7AWW7RUu4hSxr JPKJckpitjG72BV7SVUaCiYfbwG7B6m0/FqvJ59UbnfmYAjIQR2uuEKvjnJyUY8vfpvy gRg4xK2bg96grfS8/3J8aZa5excfjaXGVvxH9jKnyjfcJjp8UCErPo+RO4Iqo8kUxQTJ 1mMFIJ/DzMt/JKRmHeOzrPPoDBEIagP8eAzq79opI1jMbjTT7zujH5n4QDsjTuB/VE4/ oxRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=CSjfI0FdDG+opCSifX1YJn6xlbBS3iUU167wnFEoRhM=; b=uO8RTvm9xMYXAmXAuv5fKJPDSEwAji5yVxaXSEdxLmvjEj9BvlVShqI65BDoJ//eRG P6H4lsGbJBTxSOmePLntln0kqVVRWYJcM2i7+ZG2lobQzLEZZktUc5/ke19aJ4vsNgK+ 8umy3x/rFNMuO0XS38yQ9TwJ80GL7GmuFMH3r88qpt+MLQz0kr0ev7FVH5WilIkgwWir pYU13IChhKyfZo9RnCH8lZ4Gd51ExClHUunYkXTfcdjID1JAwXvLi6UBSM6AGe9BM6pF K6SZh7mkJAwQP557xt5ARUOkcb6LgGLhSwEpsn7+Jr4j+f67wQyTvtUb4B0nSfI6ovwF OcJg== X-Gm-Message-State: APjAAAUqyGOv4kULqf7s5laLN4O61/hpT2Ez9nOs+hDsAshzAAG8e57k tE212Y3kCZIbSN0aA778kWkGrQ== X-Received: by 2002:a17:902:6b07:: with SMTP id o7mr97652906plk.180.1560963087287; Wed, 19 Jun 2019 09:51:27 -0700 (PDT) Received: from localhost ([2620:0:1000:1601:3fed:2d30:9d40:70a3]) by smtp.gmail.com with ESMTPSA id z4sm18902897pfa.142.2019.06.19.09.51.26 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Wed, 19 Jun 2019 09:51:26 -0700 (PDT) Date: Wed, 19 Jun 2019 09:51:25 -0700 From: Sandeep Patil To: "Rafael J. Wysocki" Cc: Joel Fernandes , Tri Vo , "Rafael J. Wysocki" , Viresh Kumar , Hridya Valsaraju , Linux PM , "Cc: Android Kernel" , Greg Kroah-Hartman , LKML Subject: Re: Alternatives to /sys/kernel/debug/wakeup_sources Message-ID: <20190619165125.GG203031@google.com> References: <20190618182502.GC203031@google.com> <4587569.x9DSL43cXO@kreacher> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jun 19, 2019 at 10:35:17AM +0200, Rafael J. Wysocki wrote: > On Wed, Jun 19, 2019 at 1:52 AM Joel Fernandes wrote: > > > > On Tue, Jun 18, 2019 at 7:15 PM Tri Vo wrote: > > [snip] > > > > > > > > > > > > > > Android userspace reading wakeup_sources is not ideal because: > > > > > > > - Debugfs API is not stable, i.e. Android tools built on top of it are > > > > > > > not guaranteed to be backward/forward compatible. > > > > > > > - This file requires debugfs to be mounted, which itself is > > > > > > > undesirable for security reasons. > > > > > > > > > > > > > > To address these problems, we want to contribute a way to expose these > > > > > > > statistics that doesn't depend on debugfs. > > > > > > > > > > > > > > Some initial thoughts/questions: Should we expose the stats in sysfs? > > > > > > > Or maybe implement eBPF-based solution? What do you think? > > > > > > > > > > We are going through Android's out-of-tree kernel dependencies along with > > > > > userspace APIs that are not necessarily considered "stable and forever > > > > > supported" upstream. The debugfs dependencies showed up on our radar as a > > > > > result and so we are wondering if we should worry about changes in debugfs > > > > > interface and hence the question(s) below. > > > > > > > > > > So, can we rely on /d/wakeup_sources to be considered a userspace API and > > > > > hence maintained stable as we do for other /proc and /sys entries? > > > > > > > > > > If yes, then we will go ahead and add tests for this in LTP or > > > > > somewhere else suitable. > > > > > > > > No, debugfs is not ABI. > > > > > > > > > If no, then we would love to hear suggestions for any changes that need to be > > > > > made or we simply just move the debugfs entry into somewhere like > > > > > /sys/power/ ? > > > > > > > > No, moving that entire file from debugfs into sysfs is not an option either. > > > > > > > > The statistics for the wakeup sources associated with devices are already there > > > > under /sys/devices/.../power/ , but I guess you want all wakeup sources? > > > > > > > > That would require adding a kobject to struct wakeup_source and exposing > > > > all of the statistics as separate attributes under it. In which case it would be > > > > good to replace the existing wakeup statistics under /sys/devices/.../power/ > > > > with symbolic links to the attributes under the wakeup_source kobject. > > > > > > Thanks for your input, Rafael! Your suggestion makes sense. I'll work > > > on a patch for this. > > > > Does that entail making each wake up source, a new sysfs node under a > > particular device, and then adding stats under that new node? > > Not under a device, because there are wakeup source objects without > associated devices. > > It is conceivable to have a "wakeup_sources" directory under > /sys/power/ and sysfs nodes for all wakeup sources in there. This is what I understood from your initial reply and I think it makes sense. Thanks again, Rafael. - ssp > > Then, instead of exposing wakeup statistics directly under > /sys/devices/.../power/, there can be symbolic links from there to the > new wakeup source nodes under "wakeup_sources" (so as to avoid > exposing the same data in two different places in sysfs, which may be > confusing). > > Cheers!