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 im
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 d
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 m
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 print
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 ma
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 sure
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 uart
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 su
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 lock
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 kern
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 serial
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 printk_emergency_e
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 p
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_ deco
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 h
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 legit
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 dev_
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 va
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 linux-
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 consoles
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:
> >
> > pr_cont("Running
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 fro
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 console_lo
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
> direction to take. Thanks for the outst
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 hours of readin
31 matches
Mail list logo
