From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933809AbcJUNZb (ORCPT ); Fri, 21 Oct 2016 09:25:31 -0400 Received: from mail-qk0-f178.google.com ([209.85.220.178]:34127 "EHLO mail-qk0-f178.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933345AbcJUNZ1 (ORCPT ); Fri, 21 Oct 2016 09:25:27 -0400 Date: Fri, 21 Oct 2016 15:25:23 +0200 From: Daniel Lezcano To: "Rafael J. Wysocki" Cc: "Rafael J. Wysocki" , Linux Kernel Mailing List , Linux PM Subject: Re: [PATCH 2/2] cpuidle: governors: Move the files to the upper directory Message-ID: <20161021132523.GC1636@mai> References: <1475652794-4486-1-git-send-email-daniel.lezcano@linaro.org> <1475652794-4486-2-git-send-email-daniel.lezcano@linaro.org> <20161021130953.GB1636@mai> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Oct 21, 2016 at 03:22:18PM +0200, Rafael J. Wysocki wrote: > On Fri, Oct 21, 2016 at 3:09 PM, Daniel Lezcano > wrote: > > On Fri, Oct 21, 2016 at 02:47:22PM +0200, Rafael J. Wysocki wrote: > >> On Wed, Oct 5, 2016 at 9:33 AM, Daniel Lezcano > >> wrote: > >> > Currently the different governors are stored in the subdir > >> > 'governors'. That is not a problem. > >> > > >> > However, that forces to declare some private structure in the > >> > include/linux/cpuidle.h header because these governor files > >> > don't have access to the private 'cpuidle.h' located in > >> > drivers/cpuidle. > >> > > >> > Instead of having the governors in the separate directory, move > >> > them along with the drivers and prefix them with 'governor-', > >> > that allows to do a proper cleanup in the cpuidle headers. > >> > >> While I'm not particularly against this change, I'm sort of wondering > >> about the reason. > >> > >> What in particular would be wrong with doing > >> > >> #include "../cpuidle.h" > >> > >> in a governor .c file? > > > > Hi Rafael, > > > > there is nothing wrong by doing this relative inclusion. It is an alternative > > to the proposed patch. I personally don't like relative inclusion but it is > > a matter of taste and I am perfectly fine to resend the patch by just moving > > the structure to the private header and change the inclusion. > > > > On the other side, the cpufreq susbsytem has all the governors along with the > > drivers in the same directory, so perhaps it makes sense to have a similar files > > organization. > > > > Actually, I'm fine with both approaches. Up to you to decide. > > I'm thinking let's keep the code where it is in case people depend on > the current location somehow (ie. have patches out of the tree or > similar). We can still move it later if need be. Ok, I will resend the patch [2/2] by moving the structure from the exported header to the private header and add the relative inclusion path. Thanks. -- Daniel