linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Florian Mickler <florian@mickler.org>
To: "Ted Ts'o" <tytso@mit.edu>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>,
	Elvis Dowson <elvis.dowson@mac.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: Forked android kernel development from linux kernel mainline
Date: Wed, 10 Nov 2010 10:53:33 +0100	[thread overview]
Message-ID: <20101110105333.6ef067f2@schatten.dmk.lab> (raw)
In-Reply-To: <20101110003524.GL3099@thunk.org>

On Tue, 9 Nov 2010 19:35:24 -0500
Ted Ts'o <tytso@mit.edu> wrote:

> On Tue, Nov 09, 2010 at 10:32:25PM +0000, Alan Cox wrote:
> > > Ah, but if you make changes to the android userspace that aren't
> > > accepted upstream by the core android development team, you'll be
> > > forking the android userspace.  And given that they are continuing to
> > 
> > Oh so forking the kernel is fine but forking userspace is silly. Quaint
> OTOH, if the original poster thinks that he can develop changes to the
> Android userspace that allow the use of an upstream kernel, and has
> just as good battery lifetime, and with a system which is just as
> debuggable and easy to maintain as the current android userspace, then
> by all means, I would love for him to try to prove that he can.  And I
> will certainly be happy to introduce him to the Android developers who
> measure power usage in mobile devices using microwatt meters to see if
> he really can do as good of a job using a stock kernel.
> 
> So Elvis, if you think you can, please consider this a challenge!  :-)
> 
> Or if he just wants to get the drivers into mainline so that other
> non-Android devices can use those particular chipsets, that's good
> too.  I just hope that he can do appropriate testing so that he can be
> a good maintainer for the drivers, which means testing them.  Pushing
> code that may or may not work isn't necessarily an improvement!
> 
>        	  	    	       	     	      - Ted

I don't think _maintaining_ a fork is currently necessary or worthwile.
But what could be useful as a proove of concept, would be to try to
express the original wake-lock api (the one that is currently in use on
android) in terms of the mechanisms currently in mainline.

That way, Rafael would probably get useful feedback on
pm_wakeup_event() (and friends) implementation.

Regards,
Flo


  reply	other threads:[~2010-11-10  9:53 UTC|newest]

Thread overview: 55+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-30 18:18 Forked android kernel development from linux kernel mainline Elvis Dowson
2010-11-02 21:25 ` Janakiram Sistla
2010-11-06 18:12   ` Greg KH
2010-11-06 19:22     ` Ted Ts'o
2010-11-06 19:40       ` Anca Emanuel
2010-11-06 23:40         ` Ted Ts'o
2010-11-06 23:52           ` david
2010-11-07  0:03             ` Ted Ts'o
2010-11-07  0:13               ` Alan Cox
2010-11-07  0:20                 ` Janakiram Sistla
2010-11-09 16:30                 ` Mark Brown
2010-11-07  0:20               ` david
2010-11-10 13:54               ` Pavel Machek
2010-11-10 20:38                 ` Rafael J. Wysocki
2011-01-11 14:33                   ` Pavel Machek
2010-11-06 23:42         ` Janakiram Sistla
2010-11-06 23:09       ` Greg KH
2010-11-07  0:24         ` Randy Dunlap
2010-11-07  8:38     ` Elvis Dowson
2010-11-07 11:44       ` Anca Emanuel
2010-11-07 15:57         ` Greg KH
2010-11-07 20:06           ` Elvis Dowson
2010-11-07 21:31             ` Greg KH
2010-11-07 21:46               ` Arnaud Lacombe
2010-11-07 21:47                 ` Arnaud Lacombe
2010-11-09 18:10             ` Elvis Dowson
2010-11-09 18:24               ` Greg KH
2010-11-09 18:37                 ` Elvis Dowson
2010-11-09 18:42                   ` david
2010-11-09 18:52                     ` Elvis Dowson
2010-11-09 20:55                       ` Ted Ts'o
2010-11-09 22:32                         ` Alan Cox
2010-11-10  0:35                           ` Ted Ts'o
2010-11-10  9:53                             ` Florian Mickler [this message]
2010-11-10 20:55                             ` Alan Cox
2010-11-07 21:44           ` Arnaud Lacombe
2010-11-07 21:59             ` Greg KH
2010-11-07 23:09               ` Arnaud Lacombe
2010-11-08  1:42                 ` Greg KH
2010-11-08  2:22                   ` Arnaud Lacombe
2010-11-09 13:27                 ` Florian Fainelli
2010-11-11  0:33               ` Roland Dreier
2010-11-11  0:40                 ` Thomas Gleixner
2010-11-12  3:15                   ` Roland Dreier
2010-11-12 10:26                     ` Florian Fainelli
2010-11-11  0:47                 ` Greg KH
2010-11-11 11:21                   ` Florian Fainelli
2010-11-12  3:17                     ` Roland Dreier
2010-11-11 11:18                 ` Florian Fainelli
2010-11-09 13:27             ` Florian Fainelli
2010-11-09 13:51               ` [OpenWrt-Devel] " Wolfgang Spraul
2010-11-13  3:06             ` Arnaud Lacombe
2010-11-15 17:34             ` Stefan Monnier
2010-11-16  6:23               ` Brian Swetland
2010-11-16  7:02                 ` Anca Emanuel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20101110105333.6ef067f2@schatten.dmk.lab \
    --to=florian@mickler.org \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=elvis.dowson@mac.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tytso@mit.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).