On Tue 2020-08-25 13:38:57, David Laight wrote:
> From: Petr Mladek
> > Sent: 25 August 2020 14:11
> >
> > On Thu 2020-08-20 12:33:23, David Laight wrote:
> > > From: Petr Mladek
> > > > Sent: 20 August 2020 11:16
> > > ...
> > > > Now that I think about it. This is the biggest problem with any
From: Petr Mladek
> Sent: 25 August 2020 14:11
>
> On Thu 2020-08-20 12:33:23, David Laight wrote:
> > From: Petr Mladek
> > > Sent: 20 August 2020 11:16
> > ...
> > > Now that I think about it. This is the biggest problem with any temporary
> > > buffer
> > > for pr_cont() lines. I am more and
On Thu 2020-08-20 12:33:23, David Laight wrote:
> From: Petr Mladek
> > Sent: 20 August 2020 11:16
> ...
> > Now that I think about it. This is the biggest problem with any temporary
> > buffer
> > for pr_cont() lines. I am more and more convinced that we should just
> > _keep the current
On (20/08/20 01:32), John Ogness wrote:
> +#define CONT_LINE_MAX LOG_LINE_MAX
> +#define CONT_BUF_COUNT 10
> +static char cont_buf[CONT_BUF_COUNT][CONT_LINE_MAX];
> +static DECLARE_BITMAP(cont_buf_map, CONT_BUF_COUNT);
> +
> +static int get_cont_buf(void)
> +{
> + int bit;
> +
> + do {
> +
On (20/08/20 12:16), Petr Mladek wrote:
> Now that I think about it. This is the biggest problem with any temporary
> buffer
> for pr_cont() lines. I am more and more convinced that we should just
> _keep the current behavior_. It is not ideal. But sometimes mixed
> messages are always better
On Thu, 2020-08-20 at 07:44 +, David Laight wrote:
> From: Joe Perches
> > Sent: 20 August 2020 01:34
> >
> > On Thu, 2020-08-20 at 01:32 +0206, John Ogness wrote:
> > > Implement a new buffering mechanism for pr_cont messages.
> > >
> > > Old mechanism syntax:
> > >
> > >
From: Petr Mladek
> Sent: 20 August 2020 11:16
...
> Now that I think about it. This is the biggest problem with any temporary
> buffer
> for pr_cont() lines. I am more and more convinced that we should just
> _keep the current behavior_. It is not ideal. But sometimes mixed
> messages are always
On Thu 2020-08-20 01:32:28, John Ogness wrote:
> Implement a new buffering mechanism for pr_cont messages.
>
> Old mechanism syntax:
>
> printk(KERN_INFO "text");
> printk(KERN_CONT " continued");
> printk(KERN_CONT "\n");
>
> New mechanism syntax:
>
> pr_cont_t c;
>
>
On 2020-08-20, David Laight wrote:
>> On Thu, 2020-08-20 at 07:44 +, David Laight wrote:
>>> I've no idea how you'd 'size' the number of buffers.
>>
>> I believe they are static and assume no more than 10
>> simultaneous uses of printk_begin
>
> What I meant was how you'd work out whether 10
From: Joe Perches
> Sent: 20 August 2020 09:00
>
> On Thu, 2020-08-20 at 07:44 +, David Laight wrote:
> > I've no idea how you'd 'size' the number of buffers.
>
> I believe they are static and assume no more than 10
> simultaneous uses of printk_begin
What I meant was how you'd work out
On Thu, 2020-08-20 at 07:44 +, David Laight wrote:
> I've no idea how you'd 'size' the number of buffers.
I believe they are static and assume no more than 10
simultaneous uses of
printk_begin
+#define CONT_LINE_MAX LOG_LINE_MAX
+#define CONT_BUF_COUNT 10
+static char
From: Joe Perches
> Sent: 20 August 2020 01:34
>
> On Thu, 2020-08-20 at 01:32 +0206, John Ogness wrote:
> > Implement a new buffering mechanism for pr_cont messages.
> >
> > Old mechanism syntax:
> >
> > printk(KERN_INFO "text");
> > printk(KERN_CONT " continued");
> >
On Thu, 2020-08-20 at 01:32 +0206, John Ogness wrote:
> Implement a new buffering mechanism for pr_cont messages.
>
> Old mechanism syntax:
>
> printk(KERN_INFO "text");
> printk(KERN_CONT " continued");
> printk(KERN_CONT "\n");
>
> New mechanism syntax:
>
> pr_cont_t c;
>
>
13 matches
Mail list logo
