On Fri 2019-10-04 09:48:24, Tony Asleson wrote:
> On 9/13/19 8:26 AM, John Ogness wrote:
> > 9. Support for printk dictionaries will be discontinued. I will look
> > into who is using this and why. If printk dictionaries are important for
> > you, speak up now!
>
> I think this functionality is
On 9/13/19 8:26 AM, John Ogness wrote:
> 9. Support for printk dictionaries will be discontinued. I will look
> into who is using this and why. If printk dictionaries are important for
> you, speak up now!
I think this functionality is important.
I've been experimenting with a change which adds
On Wed 2019-09-18 12:48:01, Steven Rostedt wrote:
> On Wed, 18 Sep 2019 18:41:55 +0200
> Petr Mladek wrote:
>
> > Regarding SysRq. I could imagine introducing another SysRq that
> > would just call panic(). I mean that it would try to flush the
> > logs and reboot in the most safe way.
>
> You
On Wed, Sep 18, 2019 at 9:42 AM John Ogness wrote:
>
> On 2019-09-18, Sergey Senozhatsky wrote:
> >> For instance, tty/sysrq must be able to switch printk emergency
> >> on/off.
> >
> > How did we come up to that _sync() printk() emergency mode (when we
> > make sure that there is no active
On Wed, 18 Sep 2019 18:41:55 +0200
Petr Mladek wrote:
> Regarding SysRq. I could imagine introducing another SysRq that
> would just call panic(). I mean that it would try to flush the
> logs and reboot in the most safe way.
You mean sysrq-c ?
-- Steve
On Wed 2019-09-18 11:05:28, John Ogness wrote:
> On 2019-09-18, Sergey Senozhatsky wrote:
> >> Each console has its own iterator. This iterators will need to
> >> advance, regardless if the message was printed via write() or
> >> write_atomic().
> >
> > Great.
> >
> > ->atomic_write() path will
On (09/18/19 11:05), John Ogness wrote:
> On 2019-09-18, Sergey Senozhatsky wrote:
> >> Each console has its own iterator. This iterators will need to
> >> advance, regardless if the message was printed via write() or
> >> write_atomic().
> >
> > Great.
> >
> > ->atomic_write() path will make
On 2019-09-18, Sergey Senozhatsky wrote:
>> Each console has its own iterator. This iterators will need to
>> advance, regardless if the message was printed via write() or
>> write_atomic().
>
> Great.
>
> ->atomic_write() path will make sure that kthread is parked or will
> those compete for
On (09/18/19 09:42), John Ogness wrote:
> > It's going to be a bit harder when we have per-console kthread.
>
> Each console has its own iterator. This iterators will need to advance,
> regardless if the message was printed via write() or write_atomic().
Great.
->atomic_write() path will make
On (09/18/19 09:33), John Ogness wrote:
>
> I expect sysrq to be the only valid use of "synchronous state" other
> than oops/panic. Although I suppose PeterZ would like a boot argument to
> always run the consoles in this state.
Yes, there might be more cases when we need sync printk(). Like
On 2019-09-18, Sergey Senozhatsky wrote:
>> For instance, tty/sysrq must be able to switch printk emergency
>> on/off.
>
> How did we come up to that _sync() printk() emergency mode (when we
> make sure that there is no active printing kthread)? We had a number
> of cases (complaints) of lost
On 2019-09-18, Sergey Senozhatsky wrote:
2. A kernel thread will be created for each registered console,
each responsible for being the sole printers to their respective
consoles. With this, console printing is _fully_ decoupled from
printk() callers.
>>>
>>> sysrq over
On (09/18/19 11:36), Sergey Senozhatsky wrote:
[..]
> For instance, tty/sysrq must be able to switch printk emergency on/off.
> That already means that printk emergency knob should be visible to the
> rest of the kernel. A long time ago, we had printk_emergency_begin_sync()
> and
On (09/17/19 22:08), Steven Rostedt wrote:
> > On (09/13/19 15:26), John Ogness wrote:
> > > 2. A kernel thread will be created for each registered console, each
> > > responsible for being the sole printers to their respective
> > > consoles. With this, console printing is _fully_ decoupled from
On Wed, 18 Sep 2019 10:25:46 +0900
Sergey Senozhatsky wrote:
> On (09/13/19 15:26), John Ogness wrote:
> > 2. A kernel thread will be created for each registered console, each
> > responsible for being the sole printers to their respective
> > consoles. With this, console printing is _fully_
On (09/13/19 15:26), John Ogness wrote:
> 2. A kernel thread will be created for each registered console, each
> responsible for being the sole printers to their respective
> consoles. With this, console printing is _fully_ decoupled from printk()
> callers.
sysrq over serial?
What we currently
On 2019/09/17 22:37, Steven Rostedt wrote:
> On Tue, 17 Sep 2019 15:12:04 +0200
> Greg Kroah-Hartman wrote:
>
>>> Well, it's being used. I was thinking of dropping it if it was not.
>>> Let's keep it then.
>>
>> I think it should be dropped, only one user of the kernel is using it in
>> a
On Tue, 17 Sep 2019 15:12:04 +0200
Greg Kroah-Hartman wrote:
> > Well, it's being used. I was thinking of dropping it if it was not.
> > Let's keep it then.
>
> I think it should be dropped, only one user of the kernel is using it in
> a legitimate way, which kind of implies it isn't needed.
On Tue, Sep 17, 2019 at 09:02:54AM -0400, Steven Rostedt wrote:
> On Tue, 17 Sep 2019 09:52:16 +0200
> Petr Mladek wrote:
>
> > Heh, I did some grepping and the return value is actually used on
> > three locations:
> >
> > $> git grep "= printk("
> > drivers/scsi/aic7xxx/aic79xx_core.c:
On Tue, 17 Sep 2019 09:52:16 +0200
Petr Mladek wrote:
> Heh, I did some grepping and the return value is actually used on
> three locations:
>
> $> git grep "= printk("
> drivers/scsi/aic7xxx/aic79xx_core.c: printed = printk("%s[0x%x]", name,
> value);
> drivers/scsi/aic7xxx/aic79xx_core.c:
On Mon 2019-09-16 16:28:54, John Ogness wrote:
> On 2019-09-16, Steven Rostedt wrote:
> 9. Support for printk dictionaries will be discontinued. I will
> look into who is using this and why. If printk dictionaries are
> important for you, speak up now!
> >>>
> >>> I think that
On Mon 2019-09-16 09:43:14, Steven Rostedt wrote:
> On Mon, 16 Sep 2019 12:46:24 +0200
> Petr Mladek wrote:
> > > By the way, do we need to keep printk() return bytes like printf() ?
> > > Maybe we can make printk() return "void", for almost nobody can do
> > > meaningful things with the return
On (09/16/19 12:46), Petr Mladek wrote:
> Hmm, it seems that journalctl is able to filer device specific
> information, for example, I get:
>
> $> journalctl _KERNEL_DEVICE=+usb:2-1
> -- Logs begin at Tue 2019-08-13 09:00:03 CEST, end at Mon 2019-09-16 12:32:58
> CEST. --
> Aug 13 09:00:04
On 2019-09-16, Steven Rostedt wrote:
6. A new may-sleep function pr_flush() will be made available to
wait for all previously printk'd messages to be output on all
consoles before proceeding. For example:
pr_cont("Running test ABC... ");
pr_flush();
On Mon, 16 Sep 2019 12:46:24 +0200
Petr Mladek wrote:
> On Mon 2019-09-16 13:30:17, Tetsuo Handa wrote:
> > On 2019/09/13 22:26, John Ogness wrote:
> > > 6. A new may-sleep function pr_flush() will be made available to wait
> > > for all previously printk'd messages to be output on all
On Mon 2019-09-16 13:30:17, Tetsuo Handa wrote:
> On 2019/09/13 22:26, John Ogness wrote:
> > 6. A new may-sleep function pr_flush() will be made available to wait
> > for all previously printk'd messages to be output on all consoles before
> > proceeding. For example:
> >
> >
On Sun, Sep 15, 2019 at 3:48 PM John Ogness wrote:
>
> On 2019-09-13, Daniel Vetter wrote:
> >> 2. A kernel thread will be created for each registered console, each
> >> responsible for being the sole printers to their respective
> >> consoles. With this, console printing is _fully_ decoupled
On 2019/09/13 22:26, John Ogness wrote:
> 6. A new may-sleep function pr_flush() will be made available to wait
> for all previously printk'd messages to be output on all consoles before
> proceeding. For example:
>
> pr_cont("Running test ABC... ");
> pr_flush();
>
> do_test();
>
>
On 2019-09-13, Daniel Vetter wrote:
>> 2. A kernel thread will be created for each registered console, each
>> responsible for being the sole printers to their respective
>> consoles. With this, console printing is _fully_ decoupled from
>> printk() callers.
>
> Is the plan to split the
On Fri, Sep 13, 2019 at 3:26 PM John Ogness wrote:
>
> On 2019-09-09, Thomas Gleixner wrote:
> > printk meeting at LPC Meeting Room - SAFIRA on Tuesday Sept 10. from
> > 2PM to 3PM.
>
> The meeting was very effective in letting us come to decisions on the
>
On 2019-09-09, Thomas Gleixner wrote:
> printk meeting at LPC Meeting Room - SAFIRA on Tuesday Sept 10. from
> 2PM to 3PM.
The meeting was very effective in letting us come to decisions on the
direction to take. Thanks for the outstanding attendance! It certainly
saved hundreds of
Folks,
printk meeting at LPC Meeting Room - SAFIRA on Tuesday Sept 10. from 2PM to 3PM.
Thanks
tglx
32 matches
Mail list logo
