Message-id: <5596A58F.7090208@samsung.com>
Date: Fri, 03 Jul 2015 17:09:03 +0200
From: Marcin Niesluchowski <m.niesluchow@samsung.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101
 Thunderbird/31.7.0
MIME-version: 1.0
To: Richard Weinberger <richard.weinberger@gmail.com>
Cc: "linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
        LKML <linux-kernel@vger.kernel.org>,
        "open list:ABI/API" <linux-api@vger.kernel.org>,
        Jonathan Corbet <corbet@lwn.net>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Petr Mladek <pmladek@suse.cz>, Tejun Heo <tj@kernel.org>,
        Kay Sievers <kay@vrfy.org>, Andrew Morton <akpm@linux-foundation.org>,
        Joe Perches <joe@perches.com>,
        Karol Lewandowski <k.lewandowsk@samsung.com>,
        Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Subject: Re: [RFC 0/8] Additional kmsg devices
References: <1435920595-30879-1-git-send-email-m.niesluchow@samsung.com>
 <CAFLxGvxvaePEyCpLrB1cjNn4bvnCwt-_HE3zcT-6diMYNOraBw@mail.gmail.com>
In-reply-to: <CAFLxGvxvaePEyCpLrB1cjNn4bvnCwt-_HE3zcT-6diMYNOraBw@mail.gmail.com>
Content-type: text/plain; charset=utf-8; format=flowed
Content-transfer-encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2612
Lines: 62

On 07/03/2015 01:21 PM, Richard Weinberger wrote:
> On Fri, Jul 3, 2015 at 12:49 PM, Marcin Niesluchowski
> <m.niesluchow@samsung.com> wrote:
>> Dear All,
>>
>> This series of patches extends kmsg interface with ability to dynamicaly
>> create (and destroy) kmsg-like devices which can be used by user space
>> for logging. Logging to kernel has number of benefits, including but not
>> limited to - always available, requiring no userspace, automatically
>> rotating and low overhead.
>>
>> User-space logging to kernel cyclic buffers was already successfully used
>> in android logger concept but it had certain flaws that this commits try
>> to address:
>> * drops hardcoded number of devices and static paths in favor for dynamic
>>    configuration by ioctl interface in userspace
>> * extends existing driver instead of creating completely new one
> So, now we start moving syslogd into kernel land because userspace is
> too broken to provide
> decent logging?
>
> I can understand the systemd is using kmsg if no other logging service
> is available
> but I really don't think we should encourage other programs to do so.
>
> Why can't you just make sure that your target has a working
> syslogd/rsyslogd/journald/whatever?
> All can be done perfectly fine in userspace.
* Message credibility: Lets imagine simple service which collects logs 
via unix sockets. There is no reliable way of identifying logging 
process. getsockopt() with SO_PEERCRED option would give pid form cred 
structure, but according to manual it may not be of actual logging process:
   "The returned credentials are those that were in effect at the time 
of the call to connect(2) or socketpair(2)."
       - select(7)

* Early userspace tool: Helpful especially for embeded systems.

* Reliability: Userspace service may be killed due to out of memory 
(OOM). This is kernel cyclic buffer, which size can be specified 
differently according to situation.

* Possibility of using it with pstore: This code could be extended to 
log additional buffers to persistent storage same way main (kmsg) log 
buffer is.

* Use case of attaching file descriptor to stdout/stderr: Especially in 
early userspace.

* Performance: Those services mentioned by You are weeker solutions in 
that case. Especially systemd-journald is much too heavy soulution.

-- 

Best Regards,
Marcin Niesluchowski

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/