Impact of kernel changes on existing downstream code (Was: [UPSTREAM] Move backlight handling out of pcf50633 driver)

Rod Whitby rod at whitby.id.au
Sun Oct 19 23:55:23 CEST 2008


Clinton Ebadi wrote:
> "Mike (mwester)" <mwester at dls.net> writes:
> 
>>> As stated by
>>> Andy, most software stacks use the sysfs value to get the
>>> max_brightness. Tell us what breaks? 
>> No - if YOU want to change this, then YOU tell us why it WON'T break.
>> Right now YOU represent ONLY YOUR user-space apps -- that's not adequate.
>>
>> And no, the fact is that the requirement to use max_brightness is NOT
>> well known, or well documented -- and not all the distros use it.
>> Should they?  That's a different question.
>>
>> Just because you have excellent control over YOUR user space does not
>> entitle you or Om to make this sort of change with ONLY your input!
>> Other existing distros, ESPECIALLY the ones that actually out in common
>> use (!) should also be considered.
>>
>>> If it is new code, why not check
>>> max_brightness?
>> Yes, ****NEW*** code should do this.  But hey! News flash!  There is
>> EXISTING code for these devices, and it doesn't do that!!!   It's
>> unfortunate that I seem to be the only one advocating for that community...
> 
> If the existing code does not check max_brightness then it is
> *broken*. There is no reason to ensure that fundamentally broken code
> continues to run.

The question is not about whether the downstream code should be changed
or not (obviously it should, since it does not comply with a documented
kernel API).

The questions is how should that change to existing kernel code be
proposed and reviewed, and whether the impact on existing Openmoko
distributions is important or not.

Someone who cares nothing for the success of Openmoko in the
marketplace, will just push incompatible kernel changes through with no
regard to downstream impact.

Someone who cares about how hard it is for downstream distro maintainers
to continue keeping a distro running on the Openmoko kernel, will pause
to consider the impact of changes.

[This email makes no opinion on what has or has not been done in the
past, it is about constructive discussion about what happens in the future.]

-- Rod



More information about the openmoko-kernel mailing list