lkml.org 
[lkml]   [2015]   [Apr]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: drm/msm/mdp5: undefined CONFIG_MSM_BUS_SCALING
From
On Thu, Apr 9, 2015 at 3:44 PM, Valentin Rothberg
<valentinrothberg@gmail.com> wrote:
> On Thu, Apr 09, 2015 at 02:54:29PM -0400, Rob Clark wrote:
>> On Thu, Apr 9, 2015 at 2:12 PM, Paul Bolle <pebolle@tiscali.nl> 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.

Hmm, admittedly, I hadn't really considered the static analysis case
before today..

If at all possible, I would like to keep those, at least for the time
being, since it is one less thing for me to mess up on backports.

Not sure if a comment tag could help make things clear (for humans and
tools), ie.

#ifdef CONFIG_FOO
/* downstream bonghits */
...
#endif

no idea if that would be trivial or difficult to implement? If the
latter, I can drop those parts of the code. But if at all possible,
I'm always a fan of giving myself less things to screw up.

> 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!

No problem, and thanks for your work

BR,
-R

> Kind regards,
> Valentin
>
>>
>> BR,
>> -R
>>
>> >
>> > Paul Bolle
>> >


\
 
 \ /
  Last update: 2015-04-09 23:01    [W:0.088 / U:5.540 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site