From: Brian Swetland on
On Sun, Jun 6, 2010 at 12:05 PM, Christoph Hellwig <hch(a)infradead.org> wrote:
> On Sun, Jun 06, 2010 at 12:08:34PM -0500, James Bottomley wrote:
>> Well, we sort of tried this when Greg pulled some of them into the
>> staging tree.  The problem is that without the annotations, the drivers
>> are still different, and patches won't apply, so, unsurprisingly, they
>> didn't get improved or even maintained.
>
> Err, the biggest pile in staging was meta drivers like the binder or
> some oom killer magic which are flat out braindead and wrong and have
> no chance going into mainline anyway.  That's something different from
> real hardware drivers, although a few of those made it into staging as
> well if I remember correctly.

I was shocked when Greg pulled the binder driver and some of the other
"generic" android drivers into staging, because it was always my
assumption that nobody upstream would want them. We did get some
bugfixes for the binder driver (thanks!) but the general reaction was
pretty much the same as yours here. I then was relatively unsurprised
when it was dropped (we find it useful, upstream finds it useless, not
much else to say).

The various SoC peripheral drivers are, I suspect, much less
contentious (modulo suspend blocker usage and any necessary kernel
style cleanup).

Brian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Thomas Gleixner on
On Sun, 6 Jun 2010, Brian Swetland wrote:

> On Sun, Jun 6, 2010 at 11:04 AM, Thomas Gleixner <tglx(a)linutronix.de> wrote:
> >>
> >> Right, so the sooner we make it easier for the drivers to use the kernel
> >> as their main repository, the better.
> >
> > Yep, the fastest way is to provide two stub inlines in pm.h and let
> > the driver flood come in.
>
> As mentioned previously, we didn't know this was an option (stubs
> without an implementation behind them). If it is, and thus we can

That's what Greg did when he pulled stuff into staging, but there is
no reason not to do it outside of staging as well. We can simply put
the stub functions into Documentation/feature-removal.txt to ensure
that we don't forget about them :)

> simplify the driver merging process short-term while sorting out a
> long-term implementation or replacement for suspend blockers, then I
> think we're making real progress.

Yes, that way we do not lose the annotations. Replacing them, ripping
them out or whatever we agree on, is a nobrainer.

But it gets the drivers into the tree, so they are usable outside of
android as well and the delta between android and mainline shrinks
significantly.

Thanks,

tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Christoph Hellwig on
On Sun, Jun 06, 2010 at 12:15:10PM -0700, Brian Swetland wrote:
> I was shocked when Greg pulled the binder driver and some of the other
> "generic" android drivers into staging, because it was always my
> assumption that nobody upstream would want them. We did get some
> bugfixes for the binder driver (thanks!) but the general reaction was
> pretty much the same as yours here. I then was relatively unsurprised
> when it was dropped (we find it useful, upstream finds it useless, not
> much else to say).
>
> The various SoC peripheral drivers are, I suspect, much less
> contentious (modulo suspend blocker usage and any necessary kernel
> style cleanup).

Yes. That's what makes me wonder about some parts of the discussion
here. Getting the drivers for one or more of the android plattforms
in is not a problem. I'd say it could have easily been done with the
manweeks spent arguing in this and related threads.

The much bigger issues is to get android userspace running on a more
or less vanilla kernel, that is withoutthe binder, without the rather
interesting group ID based security hack^H^H^H^Hmodel, without the
suspend blocker userspace API and so on, and so on.

So for people who really care about running a mainline kernel on their
android device doing that part first on a generic ARM board in qemu
might be much better first step work. On the other hand I've heard
that various hardware vendors or parties closed to them are rather
annoyed by their drivers beeing stuck in the android tree - but that
can be easily solved by getting removing the suspend blockers (at least
temporarily), cleaning up a few bits here and there and getting them in.

It's not rocket science to get support for ARM SOC number 1654 into the
mainline kernel.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Brian Swetland on
On Sun, Jun 6, 2010 at 12:24 PM, Christoph Hellwig <hch(a)infradead.org> wrote:
>
> Yes.  That's what makes me wonder about some parts of the discussion
> here.  Getting the drivers for one or more of the android plattforms
> in is not a problem.  I'd say it could have easily been done with the
> manweeks spent arguing in this and related threads.
>
> The much bigger issues is to get android userspace running on a more
> or less vanilla kernel, that is withoutthe  binder, without the rather
> interesting group ID based security hack^H^H^H^Hmodel, without the
> suspend blocker userspace API and so on, and so on.

Somebody will have to broker a deal with the frameworks/apps folks to
get rid of the binder. They like it a lot. Of course if somebody
built a drop-in replacement for the userspace side that didn't require
a kernel driver, had the same performance characteristics, solved the
same problems, etc, they could probably make an argument for it (or
just provide it as a drop-in replacement for people who want a more
"pure" linux underneath Android, even if we didn't pick it up).

The group ID stuff works incredibly well for gating device access --
we ensure that devices that need access from various processes end up
with perms like 0660 root audio (say for a raw audio interface), and
then we assure that processes which have the "may use audio hardware"
permission are executed with audio as an additional group. We ended
up using the same model to control socket, raw socket, and bt socket
access because at the time we could not find a reasonable way to grant
or exclude such permissions on a process by process basis.
Maintaining about 20-30 lines of diffs to make that work was not a bad
tradeoff (and we don't expect those patches to go upstream). If
there's a way to accomplish this without patching the kernel, we're
all ears.

While we do maintain some assorted patches to core code (like the
permissions thing), we strongly prefer to keep our work localized to
drivers (generic to android or specific to hardware), and try to
migrate to common kernel features when possible, submit patches (like
work Mike Chan is doing around cpufreq and power measurement), etc.
Patches to core code cause more headaches when we rebase up to new
kernel versions, after all.

> So for people who really care about running a mainline kernel on their
> android device doing that part first on a generic ARM board in qemu
> might be much better first step work.

> On the other hand I've heard
> that various hardware vendors or parties closed to them are rather
> annoyed by their drivers beeing stuck in the android tree - but that
> can be easily solved by getting removing the suspend blockers (at least
> temporarily), cleaning up a few bits here and there and getting them in.

This continues to baffle me. If we (Google) are such a headache, why
not just route around us. The drivers we've written are GPLv2, the
source is out there for anyone who wants it, etc. The drivers other
people have written we have no control over at all. From my point of
view it'd be an annoyance if somebody took the code we wrote, modified
it heavily, and pushed it upstream, but fundamentally I can't stop
that from happening other than by pushing it upstream myself, first.

Blaming me because you want me to send your drivers upstream and I'm
not doing it or not doing it fast enough or not doing it the way you
like does not seem very productive. I'm not a gatekeeper for patch
submission to the mainline kernel.

Brian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Thomas Gleixner on
Brian,

On Sun, 6 Jun 2010, Brian Swetland wrote:

> On Sun, Jun 6, 2010 at 12:24 PM, Christoph Hellwig <hch(a)infradead.org> wrote:
> >
> > Yes.  That's what makes me wonder about some parts of the discussion
> > here.  Getting the drivers for one or more of the android plattforms
> > in is not a problem.  I'd say it could have easily been done with the
> > manweeks spent arguing in this and related threads.
> >
> > The much bigger issues is to get android userspace running on a more
> > or less vanilla kernel, that is withoutthe  binder, without the rather
> > interesting group ID based security hack^H^H^H^Hmodel, without the
> > suspend blocker userspace API and so on, and so on.
>
> Somebody will have to broker a deal with the frameworks/apps folks to
> get rid of the binder. They like it a lot. Of course if somebody
> built a drop-in replacement for the userspace side that didn't require
> a kernel driver, had the same performance characteristics, solved the
> same problems, etc, they could probably make an argument for it (or
> just provide it as a drop-in replacement for people who want a more
> "pure" linux underneath Android, even if we didn't pick it up).
>
> The group ID stuff works incredibly well for gating device access --
> we ensure that devices that need access from various processes end up
> with perms like 0660 root audio (say for a raw audio interface), and
> then we assure that processes which have the "may use audio hardware"
> permission are executed with audio as an additional group. We ended
> up using the same model to control socket, raw socket, and bt socket
> access because at the time we could not find a reasonable way to grant
> or exclude such permissions on a process by process basis.
> Maintaining about 20-30 lines of diffs to make that work was not a bad
> tradeoff (and we don't expect those patches to go upstream). If
> there's a way to accomplish this without patching the kernel, we're
> all ears.
>
> While we do maintain some assorted patches to core code (like the
> permissions thing), we strongly prefer to keep our work localized to
> drivers (generic to android or specific to hardware), and try to
> migrate to common kernel features when possible, submit patches (like
> work Mike Chan is doing around cpufreq and power measurement), etc.
> Patches to core code cause more headaches when we rebase up to new
> kernel versions, after all.

thanks for the honest answer and thanks to Christoph for the
reminder!

That takes a lot of the bullshit arguments about downstream users
being hurt out of the discussion. The above problems are way more
complex to resolve than the suspend blocker details.

That's another prove why we can let the drivers flow in (in the worst
case w/o the suspend blocker stubs) and have no pressure to resolve
the suspend blocker problem yesterday.

That said, after thinking more about it, I'm advocating the stubs
solution with a clear removal / decision date constraint
(e.g. 2.6.37), as it forces all involved parties to stay tuned and not
to forget about it. I'm curious about the outcome :)

Thanks,

tglx