Message-ID: <20111222180517.20bce47d@notabene.brown>
Date:	Thu, 22 Dec 2011 18:05:17 +1100
From:	NeilBrown <neilb@...e.de>
To:	Brian Swetland <swetland@...gle.com>
Cc:	david@...g.hm, Tim Bird <tim.bird@...sony.com>,
	Greg KH <gregkh@...e.de>,
	linux-embedded <linux-embedded@...r.kernel.org>,
	linux kernel <linux-kernel@...r.kernel.org>,
	Arnd Bergmann <arnd@...db.de>,
	john stultz <johnstul@...ibm.com>,
	Kay Sievers <kay.sievers@...y.org>,
	Lennart Poettering <lennart@...ttering.net>
Subject: Re: RFC: android logger feedback request

On Wed, 21 Dec 2011 21:06:02 -0800 Brian Swetland <swetland@...gle.com> wrote:

> On Wed, Dec 21, 2011 at 8:52 PM,  <david@...g.hm> wrote:
> > On Thu, 22 Dec 2011, NeilBrown wrote:
> >>
> >> You would defined 'read' and 'write' much like you currently do to create
> >> a list of
> >> datagrams in a circular buffer and replace the ioctls by more standard
> >> interfaces:
> >>
> >> LOGGER_GET_LOG_BUG_SIZE would use 'stat' and the st_blocks field
> >> LOGGER_GET_LOG_LEN would use 'stat' and the st_size field
> >> LOGGER_GET_NEXT_ENTRY_LEN could use the FIONREAD ioctl
> >> LOGGER_FLUSH_LOG could use ftruncate
> >>
> >> The result would be much the same amount of code, but an interface which
> >> has
> >> fewer details hard-coded and is generally more versatile and accessible.
> >
> > That sounds better than what has been done in android, but it is still _far_
> > more limited than doing something that could be replaced by a fairly
> > standard syslog daemon.
> 
> We're really not interested in adding another daemon to the platform
> -- the logging system we have has served us well, is integrated with
> our existing development tools, and we're definitely interested in
> improving it, but throwing it out and replacing it with a userspace
> solution is not interesting to us right now.
> 
> Brian

Possibly it would be useful to be clear what we all *are* really interested
in, because I suspect there is a lot of variety.

You appear to be interested in providing a great platform for a phone, in
minimising unnecessary churn in that platform, and in having the freedom to
optimise various aspects however you see fit.  You appear to have little
problem with maintaining some components out-of-mainline. This is all
perfectly valid and very much in the spirit of "freedom" that binds us
together.

Others want to be able to run a main-line kernel underneath the Android
user-space - and that is perfectly reasonable as well.

I don't much care about either of those, but I want "Linux" to be "high
quality" (according to my own personal standards of course) which means
keeping bad stuff out (though you could argue that the horse has well and
truly bolted there) and including good and useful stuff in.  And I think
Android has something to offer on both sides there :-)


Weighing all that up, I don't think it is useful to set our goal on "getting
Android to use a mainline kernel" - that isn't going to happen.
Rather we should focus primarily on "making it *possible* to run android
user-space on mainline".

That could involve two things
1/ Making sure the interfaces that Android uses are abstracted at a suitable
  level so that when running a mainline kernel you can just slip in an
  alternate shared library with compatible functionality.
2/ Adding functionality to Linux so that it is possible to provide the
  functionality that Android needs.

Android should not *have* to use the interface that the "mainline
community" decides is preferred, but nor should mainline be required to
include the drivers that Android wants to use.  History shows us that isn't
going to happen.

But if there was a fairly low-level API that Android used, then those in the
community could who want Android on a mainline kernel could work to implement
that API with whatever mixture of user-space and kernel-space that achieves
consensus.
Android could of course change to use the community version eventually if
they found that was a good thing, or could keep using their own.

So: bringing this back to the android logger...
  What I would like to see is a low-level API which is used to access logging
  for which alternate implementations could be written.  Ideally this would
  be embodied in a single .so, but we have the source so that doesn't need to
  be a barrier.
  Then we could argue to our heart's content about how best to implement that
  API - Journal and nsyslogd and rsyslogd could all implement it in different
  ways and we could be one step closer to running Android on a mainline
  kernel, but the Android developers don't need to be involved (but can if
  they want to of course).

  I would be important that the API is specified clearly - neither under
  specified nor over-specified. That means that the Android implementation
  would need to explicitly forbid anything that isn't explicit permitted.
  This is because most testing will happen on the Android platform so it's
  actual behaviour will become the defacto standard.

  Could that be a possible way forward?

NeilBrown


Download attachment "signature.asc" of type "application/pgp-signature" (829 bytes)

Powered by blists - more mailing lists