On Thu, Dec 22, 2011 at 03:12, Tim Bird <tim.bird@xxxxxxxxxxx> wrote: > On 12/21/2011 05:47 PM, Greg KH wrote: >> Again, please see what we are already doing in the kernel and userspace, >> I think a lot of the above is already implemented. > > I don't know what systemd has got going on in user-space. I'm looking > at a very recent kernel, and I see no support for multiple log channels, > or an optimized open/write path. > How does current systemd prevent user-space messages from crowding > out kernel messages? (or vice-versa). It intentionally doesn't. Splitting messages in separate stores is not what we want in the general use case. Syslog has the 'facility' for that, and it works just good enough. We think that filtering in the receiver is more flexible and useful, than to have multiple stores of pretty much the same type. If you have multiple stores, you always have to fight the ordering problem, and that really creates problems sometimes. We are very convinced, that there should be a single entry only for logging, and not multiple, and the filtering should happen on the receiver side. > Since you've been doing > a lot of work on logging, do you have any existing metrics for logging > overhead via the kernel log buffer? Which overhead? I don't really think that is too interesting. Writing to a device node or socket and copy it to the kernel's ring buffer, not sure if it has an interesting potential of being optimized, if you don't use fancy consoles and such. We have no numbers, but until I see numbers of a real world problem, I would expect there is no actual problem. >> Which brings me back to my original question, what does this code do, >> that is not already present in the kernel, and why is a totally new >> interface being proposed for it? > > At the least, it supports multiple log channels. Quite frankly my mind > has been blown a bit by the suggestion to overload the kernel log buffer > with user-space messages. I would never have gone that route. But I'll have > to find out more about this systemd thing to answer your question. It's just fine. And honestly, for early boot and debugging interleaving is exactly what you want, because userspace is triggering the actions in the kernel, and you want to see that in the same channel. Also you can use netconsole and all the weird stuff people support for the kernel and get the messages from early boot userspace including intramfs there. > Secondly, this is not a particularly new or radical interface. It is new > to legacy Linux, but it's been in the Android Linux kernel for some years > now, and it has worked well. Sure, it's understandable, it sounds like something that made sense when it was invented, and which probably still make a lot of sense for Android today. But I don't think it should be discussed as a general purpose Linux use case, or something that replaces kmsg. It does not look like too interesting for general needs today outside of Android. We probably just want the simple stuff we have today, or something that really solves the structured logging problem in a proper way. Something slightly better, with almost the same model and limitations, than what we have already, is probably not that important enough to make changes. Thanks, 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
