On Wed, 21 Dec 2011 21:06:02 -0800 Brian Swetland <swetland@xxxxxxxxxx> wrote: > On Wed, Dec 21, 2011 at 8:52 PM, <david@xxxxxxx> 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
Attachment:
signature.asc
Description: PGP signature
