Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933450AbbDITop (ORCPT ); Thu, 9 Apr 2015 15:44:45 -0400 Received: from mail-wg0-f52.google.com ([74.125.82.52]:36591 "EHLO mail-wg0-f52.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933018AbbDITom (ORCPT ); Thu, 9 Apr 2015 15:44:42 -0400 Date: Thu, 9 Apr 2015 21:44:38 +0200 From: Valentin Rothberg To: Rob Clark Cc: Paul Bolle , Greg KH , Hai Li , "dri-devel@lists.freedesktop.org" , Linux Kernel Mailing List , David Airlie , rupran@einserver.de, stefan.hengelein@fau.de Subject: Re: drm/msm/mdp5: undefined CONFIG_MSM_BUS_SCALING Message-ID: <20150409194438.GA11429@station> References: <20150409112240.GA4748@station.rsr.lip6.fr> <20150409142024.GA3040@kroah.com> <20150409170707.GA7742@kroah.com> <1428603178.13881.20.camel@x220> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3529 Lines: 74 On Thu, Apr 09, 2015 at 02:54:29PM -0400, Rob Clark wrote: > On Thu, Apr 9, 2015 at 2:12 PM, Paul Bolle wrote: > > On Thu, 2015-04-09 at 19:07 +0200, Greg KH wrote: > >> I really don't understand. Why is this code in the kernel tree if it > >> can't be built? How does anyone use this? By taking it and copying it > >> where? If it can't be built, and no one can update it, and of course > >> not run it, why is it here? What good is this code doing sitting here? > > > > The Erlangen bot (courtesy of Valentin, Stefan, and Andreas) has taken > > over what I've been doing for quite some time, but doing it much more > > thoroughly. And my experience tells me that the reports they'll send in > > will trigger more discussions like this one. > > > > A lesson I learned from my daily checks for Kconfig oddities is that > > people go to great lengths defending unbuildable code. (Do a web search > > for ATHEROS_AR231X to find a discussion that dragged on for over three > > years!) Personally I stopped caring after someone insisted on having a > > file in the tree that was in no way connected to the build system: not a > > single line in any of the Makefiles pointed at it. So, as far as I'm > > concerned, if people can't point at a patch pending, somehow, somewhere, > > that would make their code buildable one might as well delete the code. > > > > I really think it's as simple as that. > > > > In the example you reference, sure it is as simple as that. But here > we are not talking about files that aren't even referenced by build > system. We are talking about a driver which does build and run on > upstream kernel, and which has a few small #ifdef blocks to simplify > backporting to downstream kernels (which we still do need to use for > some generations and some devices) > > Sure, I'd love never to have to deal with a downstream kernel. But > really.. I didn't create the downstream mess in the arm/android > ecosystem, I'm just trying to cope with it as best as possible.. don't > hate the player, hate the game :-P I really understand your point. But I also see conflicting interests. The goal of static analysis tools such as Paul's scripts, undertaker or scripts/checkkconfigsymbols.py is to detect and ideally avoid certain kind of bugs. Having to deal with intentional dead code or entirely dead files makes such analysis quite challenging. The main issue for the tools is that as soon as there is a CONFIG_ prefixed identifier, it will be treated as a Kconfig variable. Strictly speaking, it's violating the Kconfig naming convention for the upstream case. Then there is another issue maintaining the code, studying the code, making any kind of analysis. How should people know which code is meant for upstream, downstream or other streams? Currently I am working on detecting deprecated functions, data types, etc. If there were too many of such downstream #ifdefs, it would inherently complicate affords. So I try to discourage such cases for the aforementioned reasons. But that's just my humble opinion and for sure my own interests : ) In any case, thank you a lot for taking the time explain everything in such nice detail. I learned a lot! Kind regards, Valentin > > BR, > -R > > > > > Paul Bolle > > -- 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/