On 11/06/2019 11:37 PM, Vineet Gupta wrote:
> On 11/5/19 7:03 PM, Anshuman Khandual wrote:
>> But should not pfn_pmd() be encapsulated inside
>> HAVE_ARCH_TRANSPARENT_HUGEPAGE
>> at the minimum (but I would say it should be available always, nonetheless)
>> when
>> the platform subscribes to
On Wed, Nov 06, 2019 at 09:34:40PM +0100, Peter Zijlstra wrote:
> I suppose I'm surprised there are backtraces that are not important.
> Either badness happened and it needs printing, or the user asked for it
> and it needs printing.
Or utterly meaningless.
> Perhaps we should be removing
On Wed, Nov 06, 2019 at 04:27:33PM +, Dmitry Safonov wrote:
> Hi Peter,
>
> On 11/6/19 9:20 AM, Peter Zijlstra wrote:
> > On Wed, Nov 06, 2019 at 03:04:51AM +, Dmitry Safonov wrote:
> >> Add log level argument to show_stack().
> >> Done in three stages:
> >> 1. Introducing
On Wed, Nov 06, 2019 at 07:16:38PM +0100, Geert Uytterhoeven wrote:
> > shouldn't they all just be that first one? In other words, wouldn't it be
> > better to always provide the generic ioremap prototype and unify the ports
> > instead?
>
> Agreed. But I'd go for the second one.
Eventually we
Hi Palmer,
On Wed, Nov 6, 2019 at 7:11 PM Palmer Dabbelt wrote:
> It looks like the difference in prototype between the architectures is between
>
> void __iomem *ioremap(resource_size_t, size_t)
> void __iomem *ioremap(phys_addr_t, size_t)
> void __iomem *ioremap(phys_addr_t,
On Mon, 28 Oct 2019 23:48:24 PDT (-0700), Christoph Hellwig wrote:
All MMU-enabled ports have a non-trivial ioremap and should thus provide
the prototype for their implementation instead of providing a generic
one unless a different symbol is not defined. Note that this only
affects sparc32
On 11/5/19 7:03 PM, Anshuman Khandual wrote:
> But should not pfn_pmd() be encapsulated inside HAVE_ARCH_TRANSPARENT_HUGEPAGE
> at the minimum (but I would say it should be available always, nonetheless)
> when
> the platform subscribes to THP irrespective of whether THP is enabled or not.
For
Hi Peter,
On 11/6/19 9:20 AM, Peter Zijlstra wrote:
> On Wed, Nov 06, 2019 at 03:04:51AM +, Dmitry Safonov wrote:
>> Add log level argument to show_stack().
>> Done in three stages:
>> 1. Introducing show_stack_loglvl() for every architecture
>> 2. Migrating old users with an explicit log
On 11/6/19 8:35 AM, Petr Mladek wrote:
> On Wed 2019-11-06 03:04:51, Dmitry Safonov wrote:
>> Add log level argument to show_stack().
>> Done in three stages:
>> 1. Introducing show_stack_loglvl() for every architecture
>> 2. Migrating old users with an explicit log level
>> 3. Renaming
Ok, I'll push it asap.
Thank you for your help,
Claudiu
On Tue, Nov 5, 2019 at 8:19 PM Vineet Gupta wrote:
>
> Currently for hard float we need to check for
> __ARC_FPU_SP__ || __ARC_FPU_DP__ and for soft float inverse of that.
> So define single convenience macros for either cases
>
> gcc/
>
Actually thread and process ID's are positive values. Accorting to
http://man7.org/linux/man-pages/man7/pthreads.7.html
threads are creating using "clone" syscall, so the ID generation mechanism
is similar for threads and processes. According to Linux source code
there is a function call tree,
On Wed, Nov 06, 2019 at 03:04:51AM +, Dmitry Safonov wrote:
> Add log level argument to show_stack().
> Done in three stages:
> 1. Introducing show_stack_loglvl() for every architecture
> 2. Migrating old users with an explicit log level
> 3. Renaming show_stack_loglvl() into show_stack()
>
>
On Wed 2019-11-06 03:04:51, Dmitry Safonov wrote:
> Add log level argument to show_stack().
> Done in three stages:
> 1. Introducing show_stack_loglvl() for every architecture
> 2. Migrating old users with an explicit log level
> 3. Renaming show_stack_loglvl() into show_stack()
>
>
13 matches
Mail list logo
