Received: by 2002:ac0:946b:0:0:0:0:0 with SMTP id j40csp127041imj; Thu, 14 Feb 2019 16:54:13 -0800 (PST) X-Google-Smtp-Source: AHgI3Ibryj5I72g/8G8KAgc0JSAxc7JINoLi2GItXsYwd8i64WvT6AAgPl/zQZq/mxv7o5i9N1YW X-Received: by 2002:a17:902:8f98:: with SMTP id z24mr7137524plo.40.1550192053865; Thu, 14 Feb 2019 16:54:13 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1550192053; cv=none; d=google.com; s=arc-20160816; b=s9PBchsNoF9RbFxpMDiRtnNhOzkW7QP97zeLA2m38fzFiQTkOOGce99ElSGaEAStTk U8TCGJKXXzmXopwlA1aes6ntyo91fZWwmqpM/QqD6ePf1qhUpEPFhTgvQk5KFVHARb0H /QA1w8XtYJpcfl4BHs0uCaJvUHqMI6xmqyZeLkzCAF8LMKr9XhsXLMBdSVwwyTUzxBS/ m04GaT9VEhCi5cq69DeQ7OZ4LzaUmZx7xLmXqR+puQn/Bl94XI5I6yptTLZcGKGsszpj 3BGUf+xtPo6G4bTLRvjFa/108EP4OMaVhwG1boVaHCjZICEyFQ0keJfwF6bcgIAxtx4S OHQg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=cCPhC79Ynq2GtzpgHtutBm6gZohbYSC1Gc/5fhxTbHE=; b=rxry6EAhT56fvw0iCR9BGpHnamVgPL7M5C9R2b/Q2gcmibbrJGEA2hxJA7PGWZi8bI zYTGcbJFq115p1r7yrf9heeb+JueGNTfRgrCQ7B72YLd2v83MDDu/ukJtF3HP0E559Mo Eea0Y6qIW/ue9KO+ukJlr9EbWwrZsdacNYqVH8POHviteMNSbDXhZRsgJyySQU4Ppprc S1Tj8/ysmidqhIiMQ9M33K2BMNRYSZmgK4exiNOOd0EZDPMSArR7VtLn66LQnhYVZDxp 0dA4tW73/9YEEd9DGTbGjD9m1X1QIIkL2tnzU8YC1O1NvflsuzbBRjp20ruEMVVdvQLT izOA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b="L/ZAOh68"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id c6si3920725plr.414.2019.02.14.16.53.58; Thu, 14 Feb 2019 16:54:13 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b="L/ZAOh68"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2407927AbfBNQba (ORCPT + 99 others); Thu, 14 Feb 2019 11:31:30 -0500 Received: from mail-qt1-f193.google.com ([209.85.160.193]:33047 "EHLO mail-qt1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726014AbfBNQba (ORCPT ); Thu, 14 Feb 2019 11:31:30 -0500 Received: by mail-qt1-f193.google.com with SMTP id z39so7569924qtz.0; Thu, 14 Feb 2019 08:31:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=cCPhC79Ynq2GtzpgHtutBm6gZohbYSC1Gc/5fhxTbHE=; b=L/ZAOh682bmeCwXiw0B97mMhot3GuGtPpGLnjk5NrnjiboxTg5eU4DfDFkquQUESxc 35hTyLfS2tiOzWGmn26mdEv7jm8fI8T9kU9IoPgaY9c6v2yWhHrv5eJpvZALzpVOJUZJ KXQbg+qzI8rY4P68I6ikHbHy4s+Eqd8NC6WSkbi6vGV5Hi6q/RkjSmUJ0SOekCpqLWzb oTCAo3nk2IvzbqaOfi2w6SR3nZejzwiJU22yzEeNqPIZeOEbecqMomKCQOhACe0wYgX/ cW5RZ4zyDwXE29Tkr/9PYVufgSQhkE8kd21k4/VRgdzUw0vU2fgYx6pRtqYx03xqEG7n YsSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=cCPhC79Ynq2GtzpgHtutBm6gZohbYSC1Gc/5fhxTbHE=; b=D7jCaCpRlx6HkvJs64O2F2ijrJW1JTIOwNhrduF7BXAmHx4QYf3ZXlXeBmIEgZlz9J zCqgg5Bp+siOMXsf6z5Mk7gLodlkRFLYiE0f3exV+s6ibfHfoZNdB/zCXHZ4xixUCTh0 yI5ezS0HconPIIkBs3Jh13yodGyv/zWDqKUFol2mEeKP1i212PQSNMuy2fIKIrDQo+JY szxCXJfO7pPItnJ8JTfXeDbQqeM7TWD+PQicwdYBiSqH2AGWikGfQVr9FNkl71QUfypB oQcbBp4UrstN41aSh1qGmxrwufrgAx8z882nzVpfLVCT20XMO5UAnYBpS6jAXUVJhQIw X7hw== X-Gm-Message-State: AHQUAuaD3S6YjFy4OBcREo1XIoBBUQgs8UGGaLEnyZ5IR2Jpl8inFphC JbhCVK6hMS654xXrFYTUxjfbZ3VMhk9JNAVXx5o= X-Received: by 2002:ac8:1625:: with SMTP id p34mr3677365qtj.95.1550161889019; Thu, 14 Feb 2019 08:31:29 -0800 (PST) MIME-Version: 1.0 References: <1550124158-1111-1-git-send-email-xiaoxiang@xiaomi.com> <1550124158-1111-2-git-send-email-xiaoxiang@xiaomi.com> <20190214130940.GV9224@smile.fi.intel.com> In-Reply-To: <20190214130940.GV9224@smile.fi.intel.com> From: xiang xiao Date: Fri, 15 Feb 2019 00:31:17 +0800 Message-ID: Subject: Re: [PATCH V2 2/2] rpmsg: add syslog redirection driver To: Andy Shevchenko Cc: Randy Dunlap , Greg KH , alexander.shishkin@linux.intel.com, Ohad Ben Cohen , Bjorn Andersson , wendy.liang@xilinx.com, Arnaud POULIQUEN , Kumar Gala , linux-remoteproc@vger.kernel.org, linux-kernel@vger.kernel.org, Guiding Li Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Feb 14, 2019 at 9:09 PM Andy Shevchenko wrote: > > On Thu, Feb 14, 2019 at 02:02:38PM +0800, Xiang Xiao wrote: > > From: Guiding Li > > > > This driver allows the remote processor to redirect the output of > > syslog or printf into the kernel log, which is very useful to see > > what happen in the remote side. > > > +struct rpmsg_syslog_header { > > + u32 command; > > + s32 result; > > +} __packed; > > Isn't packed already? > But, I want to make it more explicitly and prepare for struct expansion later. > > +struct rpmsg_syslog_transfer { > > + struct rpmsg_syslog_header header; > > + u32 count; > > + char data[0]; > > +} __packed; > > Ditto. > > > +static int rpmsg_syslog_callback(struct rpmsg_device *rpdev, > > + void *data, int len, void *priv_, u32 src) > > +{ > > + struct rpmsg_syslog *priv = dev_get_drvdata(&rpdev->dev); > > + struct rpmsg_syslog_transfer *msg = data; > > + struct rpmsg_syslog_transfer_done done; > > + unsigned int copied = msg->count; > > + unsigned int printed = 0; > > + const char *nl; > > + > > + if (msg->header.command != RPMSG_SYSLOG_TRANSFER) > > + return -EINVAL; > > + > > + /* output the message before '\n' to the kernel log */ > > + nl = memrchr(msg->data, '\n', msg->count); > > Hmm... To me it sounds somehow fragile. > > If your text contains binary data, how can you guarantee that it would be not > in the middle of two \n:s? This driver is just for log/printf redirection, so we could safely assume the data is pure text. We have another rpmsg driver(rpmsg-tty) for binary data transfer. > OTOH, if it text data, why do you need to take all strings at once? Remote side may decide to buffer more log to reduce the IPC number since IPC is a time consuming operation. > It might be worse from performance prospective (if you know how and when printk() supplies buffer to the console). Yes, it's very slow if the log send to serial console. But in production environment, printk normally just save in ram and viewed by dmesg which is very fast. > > > + if (nl) { > > + printed = nl + 1 - msg->data; > > + copied = msg->count - printed; > > + > > + if (priv->next) { > > + pr_info("%.*s%.*s", priv->next, > > + priv->buf, printed, msg->data); > > + priv->next = 0; > > + } else { > > + pr_info("%.*s", printed, msg->data); > > + } > > + } > > + > > + /* append the message after '\n' to the buffer */ > > > + if (copied != 0) { > > > > > + unsigned int newsize = priv->next + copied; > > + > > + if (newsize > priv->size) { > > + char *newbuf; > > + > > + newbuf = krealloc(priv->buf, newsize, GFP_KERNEL); > > + if (newbuf) { > > + priv->buf = newbuf; > > + priv->size = newsize; > > + } else { > > + copied = priv->size - priv->next; > > + } > > + } > > + > > > + strncpy(priv->buf + priv->next, msg->data + printed, copied); > > Hmm... shouldn't be memcpy()? I use memcpy initially, but found that the unaligned exception happen randomly. To avoid the cache issue, the IPC memory normally map as device memory, but ARM just allow the alignment access to this type of memory. > > > + priv->next += copied; > > + } > > + > > + done.command = RPMSG_SYSLOG_TRANSFER_DONE; > > + done.result = printed + copied; > > + return rpmsg_send(rpdev->ept, &done, sizeof(done)); > > +} > > + > > +static int rpmsg_syslog_probe(struct rpmsg_device *rpdev) > > +{ > > + struct rpmsg_syslog *priv; > > + > > + priv = devm_kzalloc(&rpdev->dev, sizeof(*priv), GFP_KERNEL); > > + if (!priv) > > + return -ENOMEM; > > + > > + dev_set_drvdata(&rpdev->dev, priv); > > + return 0; > > +} > > + > > +static void rpmsg_syslog_remove(struct rpmsg_device *rpdev) > > +{ > > + struct rpmsg_syslog *priv = dev_get_drvdata(&rpdev->dev); > > + > > > + /* flush the buffered log if need */ > > + if (priv->next) > > + pr_info("%.*s\n", priv->next, priv->buf); > > + kfree(priv->buf); > > I don't see how it's serialized. Does rpmsg core take care of this? Yes, the callback come from a dedicated work thread. > > > +} > > > +#ifdef CONFIG_PM_SLEEP > > You can consider to use __maybe_unused annotation to the below function. Ok. > > > +static int rpmsg_syslog_dev_suspend(struct device *dev) > > +{ > > > +} > > + > > +static int rpmsg_syslog_dev_resume(struct device *dev) > > +{ > > > +} > > +#endif > > > +static const struct rpmsg_device_id rpmsg_syslog_id_table[] = { > > + { .name = "rpmsg-syslog" }, > > + { }, > > Terminator better without comma. Ok. > > > +}; > > -- > With Best Regards, > Andy Shevchenko > >