lkml.org 
[lkml]   [2011]   [Dec]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: RFC: android logger feedback request
    On Wed, 21 Dec 2011 21:06:02 -0800 Brian Swetland <swetland@google.com> wrote:

    > On Wed, Dec 21, 2011 at 8:52 PM, <david@lang.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

    [unhandled content-type:application/pgp-signature]
    \
     
     \ /
      Last update: 2011-12-22 08:07    [from the cache]
    ©2003-2011 Jasper Spaans