On Tue, 18 Dec 2018, Ingo Molnar wrote:
> * Linus Torvalds wrote:
> > So thinking that early_printk is any better is just puting your head in
> > the sand.
>
> ... at my own feet. ;-) Apologies to the syslog folks!
>
> early_printk should still in principle be more robust: it tries to use as
>
* Linus Torvalds wrote:
> On Mon, Dec 17, 2018 at 10:17 AM Ingo Molnar wrote:
> >
> > We should rename printk() to syslog() or so, and rename early_printk() to
> > printk(), and be done with this.
>
> No.
>
> As already pointed out, the syslog part isn't the issue. The printing
> part is the
On (12/17/18 19:17), Ingo Molnar wrote:
> This makes me sad - whatever happened to the principle of keeping printk
> simple?
printk() is still simple. Console drivers are not, tho.
-ss
On Mon, Dec 17, 2018 at 10:17 AM Ingo Molnar wrote:
>
> We should rename printk() to syslog() or so, and rename early_printk() to
> printk(), and be done with this.
No.
As already pointed out, the syslog part isn't the issue. The printing
part is the issue.
So thinking that early_printk is any
On Mon, Dec 17, 2018 at 07:17:12PM +0100, Ingo Molnar wrote:
> and rename early_printk() to printk(), and be done with this.
git://git.kernel.org/pub/scm/linux/kernel/git/peterz/queue.git
debug/experimental
:-)
On 12/17/2018 01:17 PM, Ingo Molnar wrote:
> * Waiman Long wrote:
>
>> The db->lock is a raw spinlock and so the lock hold time is supposed to
>> be short. This will not be the case when printk() is being involved in
>> some of the critical sections.
>>
>> In order to avoid the long hold time, in
* Waiman Long wrote:
> The db->lock is a raw spinlock and so the lock hold time is supposed to
> be short. This will not be the case when printk() is being involved in
> some of the critical sections.
>
> In order to avoid the long hold time, in case some messages need to be
> printed, all the
7 matches
Mail list logo