All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joe Perches <joe@perches.com>
To: Kay Sievers <kay@vrfy.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: pr_cat() + CATSTR(name, size)?
Date: Wed, 11 Jul 2012 09:55:43 -0700	[thread overview]
Message-ID: <1342025743.13724.102.camel@joe2Laptop> (raw)
In-Reply-To: <CAPXgP13ff+eFH_jJ+0FDX0-GkuZj3RSv7VCp3ftcsGzA412FVQ@mail.gmail.com>

On Wed, 2012-07-11 at 17:48 +0200, Kay Sievers wrote:
> On Wed, Jul 11, 2012 at 5:30 PM, Joe Perches <joe@perches.com> wrote:
> > Well, I think the malloc costs are pretty low
> > and could devolve pretty easily when OOM.
> 
> We need to avoid allocating memory in situations where we want to
> printk(), it's just not possible.

"it's just not possible???"  Kay, them's fightin' words. :)

> That's why all the kmsg/printk can
> not really do any plain malloc. All printk memory needs to be static,
> on the stack or somehow pre-allocated.

Maybe, I was planning to play with it after
refactoring printk in the next couple releases.

> > Anyway, interesting idea, keep at it, see what
> > comes out of it.
> 
> Just depends on us, I guess. :)

Yup.

If your solution is just for the dev_<level> messages
(ie: with vprintk_emit descriptors), then it's not
too ugly.

Did you look at the remaining dev_<level> and printk
continuations grep pattern?  There really aren't too
many to fix up.

Maybe in 3.6.  None of them appear particularly urgent.

One trivial style note:

Maybe CATSTR could use a struct and a DECLARE_ macro?

struct printk_continuation_buffer {
	size_t length;
	size_t pos;
	char buf[];
}

It's a pity gcc doesn't allow non-static declarations like:

#define DECLARE_PRINTK_BUF(name, size)		\
struct printk_continuation_buffer name = {	\
	.length = size;				\
	.pos = 0;				\
	.buf[size] = {0};			\
}

So maybe a DECLARE/DESTROY thing could work
with the appropriate malloc/free.

cheers, Joe


  reply	other threads:[~2012-07-11 16:55 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-11 10:33 pr_cat() + CATSTR(name, size)? Kay Sievers
2012-07-11 11:38 ` Kay Sievers
2012-07-11 15:01 ` Joe Perches
2012-07-11 15:14   ` Kay Sievers
2012-07-11 15:30     ` Joe Perches
2012-07-11 15:48       ` Kay Sievers
2012-07-11 16:55         ` Joe Perches [this message]
2012-07-11 17:25           ` Kay Sievers
2012-07-11 17:51             ` Joe Perches
2012-07-12 12:04               ` Kay Sievers

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1342025743.13724.102.camel@joe2Laptop \
    --to=joe@perches.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=kay@vrfy.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.