On Thu, Dec 22, 2011 at 15:59, Arnd Bergmann <arnd@xxxxxxxx> wrote: > * Remove all kernel code for this and use a user space library together > with tmpfs > * prepopulate the tmpfs at boot time with all the log buffers in the right > size, and set the maximum file system size so that they cannot grow further. > * Have minimal formatting in the log buffer: A few bytes header (ring buffer > start and end) > * Mandate that user space must use mmap and atomic operations to reserve space > in the log and write to the files. > * Provide a tool to get the log data out of the buffer again in a race-free way. > > Since any program that is allowed to write to the buffer can overwrite all > existing information in it anyway, I think we don't actually need any kernel > help in maintaining consistency of the contents either -- the reader will > simply discard any data. The main thing we would not be able to guarantee > without kernel help is proving the origin of individual messages, but I'm > not sure if that is a design goal. I'm very sure you want rate limiting, global sequence numbers and trusted properties added to the log. I can imagine that the kernel provides a single character device, instantiates a tmpfs mountpoint and splits all stuff that travels into that device into several files (ring buffers) in the tmpfs filesystem. The files are probably just split by the uid of the incoming message sender, which maps to an app at Android. Only the character device would be able to write to the file, but the user with the matching uid can read its own file back directly from tmpfs. I'm very convinced that we should not design a logging system today, where we give the ownership of the data to the actual untrusted process that logs. The current kmsg buffer could just be one additional file in this tmpfs mount. Kay -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
