|| ||Brian Swetland <swetland-AT-google.com> |
|| ||david-AT-lang.hm |
|| ||Re: RFC: android logger feedback request |
|| ||Wed, 21 Dec 2011 21:25:52 -0800|
|| ||NeilBrown <neilb-AT-suse.de>, Tim Bird <tim.bird-AT-am.sony.com>,
Greg KH <gregkh-AT-suse.de>,
linux kernel <linux-kernel-AT-vger.kernel.org>,
Arnd Bergmann <arnd-AT-arndb.de>,
john stultz <johnstul-AT-us.ibm.com>,
Kay Sievers <kay.sievers-AT-vrfy.org>,
Lennart Poettering <lennart-AT-poettering.net>|
|| ||Article, Thread
On Wed, Dec 21, 2011 at 9:14 PM, <email@example.com> wrote:
> On Wed, 21 Dec 2011, Brian Swetland wrote:
>> 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.
> Think very hard before you reject any possibility of doing this in
> userspace, especially with all the things that you are talking about doing
> with logging in the future. I really don't think aht a lot of your
> long-0term plans for logging are going to sit well with the kernel
> developers, and if your justification is "you don't want to change your
> build process", I really doubt that you will get this upstream.
> It should be possible to do this without having to change the tools writing
> the logs, any change in logging will change what it takes to read the logs.
> I am not saying that you need to have a logging daemon as heavyweight as
> syslog-ng or rsyslog for the low-end phones, but I do think that as android
> moves up the stack a bit into talets and netbooks (especially in
> applications where it will have wifi connectivity almost all the time)
> having the capability to move to a full-blown syslog daemon will make a huge
> amount of sense, so you should look at how big a minimalist daemon would be,
> and what sort of performance it would have.
Long term things could certainly move around, but *right now* we
really don't see the value in gutting what we've got in favor of
writing a new userspace daemon, which is going to require somebody to
do that work, maintain it, chase down any behavioural quirks
introduced by the changes, etc. Or to throw it out in favor of trying
to bolt our logging infrastructure on top of existing syslogds, etc.
We're happy to maintain the logger driver out of tree as we have for
the past four years.
If all discussions of bringing Android kernel support to mainline end
up as another round of "you should just rewrite it all in userspace"
or "you should use this other subsystem that doesn't actually solve
your problem but we think it's close enough", then there's not a lot
of point to having the discussions in the first place.
If somebody wants to go write a complete compatible replacement that
just drops in, we certainly could take a look at it and see how it
works, but given that the benefits are not clear to us, we're not
interested in going off and doing that work ourselves.
to post comments)