On 09/07/2008, Mike (mwester) <mwester at dls.net> wrote:
> Sean McNeil wrote:
> > This is an area I have a strong opinion about...
>> As do I.
>> > IMHO, OLPC is doing the right thing here as an application. The kernel
> > provides functionality and does things at a very low level. You do not
> > want it to be providing any utilitarian functionality.
>> Theoretically, I agree.
>> > I would disagree
> > that there is compromise necessary. Sure, one can have debug code that
> > turns on the display coming out of sleep, but a release should do the
> > right thing and leave the display in exactly the same condition it was
> > in when it entered suspend.
>> Ok, but you *DO* agree that there is a compromise necessary. I'm asking
> for nothing more than *EXACTLY* what you are suggesting here -- while
> this kernel and this hardware is in its current state, we need to make a
> compromise on these principles of purity, etc. and do the right thing
> for the user. That's all I'm asking for!
>> > This is the same reasoning I don't want any of the LEDs to be doing
> > utilitarian things like being changed when external power is
> > applied/removed - the kernel is not an application. I would be surprised
> > if application capabilities such as these manage to make it upstream
> > into the main kernel tree.
>> !!! Upstream??!!!!! (Ok, I went outside and screamed. I feel better
> now.) Now a general rant on this myopic focus on upstream, aimed at
> nobody in particular, and the entire OM development team specifically
Here's my rant too:
Upstream is not a monster that we (or specifically Andy) get attacked
by when we do something that it doesn't like. If we suspect something
we'll not make it upstream, that's a very good indication that you're
doing it wrong and soon it will bite you. Linux upstream is not that
picky so it's a strong indication. Upstream is just helpful. Thinking
that it's a good idea to maintain the hacks locally - this is myopic.
I'm sure the great majority of people who bought Openmoko phones did
that because they wanted a Linux device - definitely not to replace
their old phones, right? So to keep the users happy you need to, more
than anything, make a Linux device. For your kernel to be still the
Linux kernel, when you add new code the code needs to go with the
Linux ways.
Considering this, I'd say that some of those hired for the kernel
hacking while they are brilliant phone hackers, they're no Linux
hackers, they would much rather only base their kernel on Linux
instead, zaurus style.
Your argument about always resuming backlight is similar to Andy's
beauty contest argument... and it's bogus. Take the kernel as it is
now on the Neo and take the same kernel but hacked to skip permission
(uid/gid) checks when using the fs. We have completely no use for
these checks and they add a little overhead on thousands of the
filesystem calls we do. We run everything as root ( + some things
perhaps as nobody but they'll cope), so why not remove them. Same with
many other features. Turns out that the original kernel wins the
contest (in maintainability and appeal to the users, even though it
loses in power consumption), and this is not in my head.
>> Users care that it works, and care nothing for things like elegance of
> algorithm, or ability to push upstream. As such there will be constant
> friction; development for the sake of elegance and purity is a thing of
> beauty, a wonderful art-form. But it's been my experience that users
> seldom pay for "art" and "purity" and "elegance" if the device fails to
> deliver, reliably, on its primary purpose. People pay for results, not
> elegance, especially when they can't see the elegance and beauty of the
> code when it's in binary form in flash anyway.
>> So, the OM thinking on this issue and on so many we've discussed in the
> past is that code should always be Pure, and Elegant, and it should
> always do what is "The Right Thing To Do(tm)" -- in this case, not turn
> on the backlight in the kernel. Agreed - at least I do agree that's the
> elegant thing to do. And also agreed is that to do otherwise will cause
> the code not go upstream.
>> But to continue to pick on this single example we are discussing now, do
> any of you appreciate what sort of response you'll get from the user who
> has a non-responsive device with a blank screen in their hand? Will you
> explain to him that the code leaving the screen dark is not only
> deliberate, it is considered a thing of beauty, a bit of elegance in
> programming, and then will you inquire if the user is delighted to know
> that this code that left his display dark and his device undiagnosable,
> that bit of code was accepted upstream and will be part of the Linux
> kernel in the future? Hurray! I'm quite certain the user of that
> defunct device will be absolutely delighted to hear about that; this
> knowledge cannot fail to soothe any frustrations the user may have over
> the complete inability to determine what failed and the true state of
> the device with the dark display in his hand.
To see anything on the LCD you need the backlight, the LCD controller
and various other parts resumed. But if you're checking whether to
really resume, or go back to suspend, you don't want to power up
anything that's not needed before this check. Userspace is much too
late for this. I'd say even the kernel possibly is too late (there's
u-boot before). When you hit userspace, all your processes are again
in the "RUNNING" state (even before your daemon actually starts to
execute), including your mp3 player and anything you had left running
when you suspended (imagine the kernel is a zoo and the processes are
wild crazy animals, that you free all at once when you let userspace
run, somewhere in the mess is your daemon).
Cheers