All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vladimir Murzin <vladimir.murzin@arm.com>
To: Christoph Hellwig <hch@lst.de>
Cc: Palmer Dabbelt <palmer@sifive.com>,
	Damien Le Moal <damien.lemoal@wdc.com>,
	linux-riscv@lists.infradead.org, uclinux-dev@uclinux.org,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 02/17] mm: stub out all of swapops.h for !CONFIG_MMU
Date: Tue, 11 Jun 2019 15:36:53 +0100	[thread overview]
Message-ID: <80d01a1d-b6b0-18e8-811c-71af14cba3b9@arm.com> (raw)
In-Reply-To: <20190611141841.GA29151@lst.de>

On 6/11/19 3:18 PM, Christoph Hellwig wrote:
> On Tue, Jun 11, 2019 at 11:15:44AM +0100, Vladimir Murzin wrote:
>> On 6/10/19 11:16 PM, Christoph Hellwig wrote:
>>> The whole header file deals with swap entries and PTEs, none of which
>>> can exist for nommu builds.
>>
>> Although I agree with the patch, I'm wondering how you get into it?
> 
> Without that the RISC-V nommu blows up like this:
> 
> 
> In file included from mm/vmscan.c:58:
> ./include/linux/swapops.h: In function ‘pte_to_swp_entry’:
> ./include/linux/swapops.h:71:15: error: implicit declaration of function ‘__pte_to_swp_entry’; did you mean ‘pte_to_swp_entry’? [-Werror=implicit-function-declaration]
>   arch_entry = __pte_to_swp_entry(pte);
>                ^~~~~~~~~~~~~~~~~~
>                pte_to_swp_entry
> ./include/linux/swapops.h:71:13: error: incompatible types when assigning to type ‘swp_entry_t’ {aka ‘struct <anonymous>’} from type ‘int’
>   arch_entry = __pte_to_swp_entry(pte);
>              ^
> ./include/linux/swapops.h:72:19: error: implicit declaration of function ‘__swp_type’; did you mean ‘swp_type’? [-Werror=implicit-function-declaration]
>   return swp_entry(__swp_type(arch_entry), __swp_offset(arch_entry));
>                    ^~~~~~~~~~
>                    swp_type
> ./include/linux/swapops.h:72:43: error: implicit declaration of function ‘__swp_offset’; did you mean ‘swp_offset’? [-Werror=implicit-function-declaration]
>   return swp_entry(__swp_type(arch_entry), __swp_offset(arch_entry));
>                                            ^~~~~~~~~~~~
>                                            swp_offset
> ./include/linux/swapops.h: In function ‘swp_entry_to_pte’:
> ./include/linux/swapops.h:83:15: error: implicit declaration of function ‘__swp_entry’; did you mean ‘swp_entry’? [-Werror=implicit-function-declaration]
>   arch_entry = __swp_entry(swp_type(entry), swp_offset(entry));
>                ^~~~~~~~~~~
>                swp_entry
> ./include/linux/swapops.h:83:13: error: incompatible types when assigning to type ‘swp_entry_t’ {aka ‘struct <anonymous>’} from type ‘int’
>   arch_entry = __swp_entry(swp_type(entry), swp_offset(entry));
>              ^
> ./include/linux/swapops.h:84:9: error: implicit declaration of function ‘__swp_entry_to_pte’; did you mean ‘swp_entry_to_pte’? [-Werror=implicit-function-declaration]
>   return __swp_entry_to_pte(arch_entry);
>          ^~~~~~~~~~~~~~~~~~
>          swp_entry_to_pte
> ./include/linux/swapops.h:84:9: error: incompatible types when returning type ‘int’ but ‘pte_t’ {aka ‘struct <anonymous>’} was expected
>   return __swp_entry_to_pte(arch_entry);
>          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> cc1: some warnings being treated as errors
> make[1]: *** [scripts/Makefile.build:278: mm/vmscan.o] Error 1
> make: *** [Makefile:1071: mm] Error 2
> make: *** Waiting for unfinished jobs....
> 

It looks like NOMMU ports tend to define those. For ARM they are:

#define __swp_type(x)           (0)
#define __swp_offset(x)         (0)
#define __swp_entry(typ,off)    ((swp_entry_t) { ((typ) | ((off) << 7)) })
#define __pte_to_swp_entry(pte) ((swp_entry_t) { pte_val(pte) })
#define __swp_entry_to_pte(x)   ((pte_t) { (x).val })

Anyway, I have no strong opinion on which is better :)

Cheers
Vladimir

WARNING: multiple messages have this Message-ID (diff)
From: Vladimir Murzin <vladimir.murzin@arm.com>
To: Christoph Hellwig <hch@lst.de>
Cc: Damien Le Moal <damien.lemoal@wdc.com>,
	uclinux-dev@uclinux.org, Palmer Dabbelt <palmer@sifive.com>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	linux-riscv@lists.infradead.org
Subject: Re: [PATCH 02/17] mm: stub out all of swapops.h for !CONFIG_MMU
Date: Tue, 11 Jun 2019 15:36:53 +0100	[thread overview]
Message-ID: <80d01a1d-b6b0-18e8-811c-71af14cba3b9@arm.com> (raw)
In-Reply-To: <20190611141841.GA29151@lst.de>

On 6/11/19 3:18 PM, Christoph Hellwig wrote:
> On Tue, Jun 11, 2019 at 11:15:44AM +0100, Vladimir Murzin wrote:
>> On 6/10/19 11:16 PM, Christoph Hellwig wrote:
>>> The whole header file deals with swap entries and PTEs, none of which
>>> can exist for nommu builds.
>>
>> Although I agree with the patch, I'm wondering how you get into it?
> 
> Without that the RISC-V nommu blows up like this:
> 
> 
> In file included from mm/vmscan.c:58:
> ./include/linux/swapops.h: In function ‘pte_to_swp_entry’:
> ./include/linux/swapops.h:71:15: error: implicit declaration of function ‘__pte_to_swp_entry’; did you mean ‘pte_to_swp_entry’? [-Werror=implicit-function-declaration]
>   arch_entry = __pte_to_swp_entry(pte);
>                ^~~~~~~~~~~~~~~~~~
>                pte_to_swp_entry
> ./include/linux/swapops.h:71:13: error: incompatible types when assigning to type ‘swp_entry_t’ {aka ‘struct <anonymous>’} from type ‘int’
>   arch_entry = __pte_to_swp_entry(pte);
>              ^
> ./include/linux/swapops.h:72:19: error: implicit declaration of function ‘__swp_type’; did you mean ‘swp_type’? [-Werror=implicit-function-declaration]
>   return swp_entry(__swp_type(arch_entry), __swp_offset(arch_entry));
>                    ^~~~~~~~~~
>                    swp_type
> ./include/linux/swapops.h:72:43: error: implicit declaration of function ‘__swp_offset’; did you mean ‘swp_offset’? [-Werror=implicit-function-declaration]
>   return swp_entry(__swp_type(arch_entry), __swp_offset(arch_entry));
>                                            ^~~~~~~~~~~~
>                                            swp_offset
> ./include/linux/swapops.h: In function ‘swp_entry_to_pte’:
> ./include/linux/swapops.h:83:15: error: implicit declaration of function ‘__swp_entry’; did you mean ‘swp_entry’? [-Werror=implicit-function-declaration]
>   arch_entry = __swp_entry(swp_type(entry), swp_offset(entry));
>                ^~~~~~~~~~~
>                swp_entry
> ./include/linux/swapops.h:83:13: error: incompatible types when assigning to type ‘swp_entry_t’ {aka ‘struct <anonymous>’} from type ‘int’
>   arch_entry = __swp_entry(swp_type(entry), swp_offset(entry));
>              ^
> ./include/linux/swapops.h:84:9: error: implicit declaration of function ‘__swp_entry_to_pte’; did you mean ‘swp_entry_to_pte’? [-Werror=implicit-function-declaration]
>   return __swp_entry_to_pte(arch_entry);
>          ^~~~~~~~~~~~~~~~~~
>          swp_entry_to_pte
> ./include/linux/swapops.h:84:9: error: incompatible types when returning type ‘int’ but ‘pte_t’ {aka ‘struct <anonymous>’} was expected
>   return __swp_entry_to_pte(arch_entry);
>          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> cc1: some warnings being treated as errors
> make[1]: *** [scripts/Makefile.build:278: mm/vmscan.o] Error 1
> make: *** [Makefile:1071: mm] Error 2
> make: *** Waiting for unfinished jobs....
> 

It looks like NOMMU ports tend to define those. For ARM they are:

#define __swp_type(x)           (0)
#define __swp_offset(x)         (0)
#define __swp_entry(typ,off)    ((swp_entry_t) { ((typ) | ((off) << 7)) })
#define __pte_to_swp_entry(pte) ((swp_entry_t) { pte_val(pte) })
#define __swp_entry_to_pte(x)   ((pte_t) { (x).val })

Anyway, I have no strong opinion on which is better :)

Cheers
Vladimir

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

  reply	other threads:[~2019-06-11 14:36 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-10 22:16 RISC-V nommu support Christoph Hellwig
2019-06-10 22:16 ` Christoph Hellwig
2019-06-10 22:16 ` [PATCH 01/17] mm: provide a print_vma_addr stub for !CONFIG_MMU Christoph Hellwig
2019-06-10 22:16   ` Christoph Hellwig
2019-06-11 10:11   ` Vladimir Murzin
2019-06-11 10:11     ` Vladimir Murzin
2019-06-10 22:16 ` [PATCH 02/17] mm: stub out all of swapops.h " Christoph Hellwig
2019-06-10 22:16   ` Christoph Hellwig
2019-06-11 10:15   ` Vladimir Murzin
2019-06-11 10:15     ` Vladimir Murzin
2019-06-11 14:18     ` Christoph Hellwig
2019-06-11 14:18       ` Christoph Hellwig
2019-06-11 14:36       ` Vladimir Murzin [this message]
2019-06-11 14:36         ` Vladimir Murzin
2019-06-14  9:48         ` Christoph Hellwig
2019-06-14  9:48           ` Christoph Hellwig
2019-06-10 22:16 ` [PATCH 03/17] mm/nommu: fix the MAP_UNINITIALIZED flag Christoph Hellwig
2019-06-10 22:16   ` Christoph Hellwig
2019-06-11 10:19   ` Vladimir Murzin
2019-06-11 10:19     ` Vladimir Murzin
2019-06-10 22:16 ` [PATCH 04/17] irqchip/sifive-plic: set max threshold for ignored handlers Christoph Hellwig
2019-06-10 22:16   ` Christoph Hellwig
2019-06-10 22:16 ` [PATCH 05/17] riscv: use CSR_SATP instead of the legacy sptbr name in switch_mm Christoph Hellwig
2019-06-10 22:16   ` Christoph Hellwig
2019-06-10 22:16 ` [PATCH 06/17] riscv: clear the instruction cache and all registers when booting Christoph Hellwig
2019-06-10 22:16   ` Christoph Hellwig
2019-06-10 22:16 ` [PATCH 07/17] riscv: refactor the IPI code Christoph Hellwig
2019-06-10 22:16   ` Christoph Hellwig
2019-06-10 22:16 ` [PATCH 08/17] riscv: abstract out CSR names for supervisor vs machine mode Christoph Hellwig
2019-06-10 22:16   ` Christoph Hellwig
2019-06-10 22:16 ` [PATCH 09/17] riscv: improve the default power off implementation Christoph Hellwig
2019-06-10 22:16   ` Christoph Hellwig
2019-06-10 22:16 ` [PATCH 10/17] riscv: provide a flat entry loader Christoph Hellwig
2019-06-10 22:16   ` Christoph Hellwig
2019-06-10 22:16 ` [PATCH 11/17] riscv: read hart ID from mhartid on boot Christoph Hellwig
2019-06-10 22:16   ` Christoph Hellwig
2019-06-10 22:16 ` [PATCH 12/17] riscv: provide native clint access for M-mode Christoph Hellwig
2019-06-10 22:16   ` Christoph Hellwig
2019-06-10 22:16 ` [PATCH 13/17] riscv: implement remote sfence.i natively " Christoph Hellwig
2019-06-10 22:16   ` Christoph Hellwig
2019-06-10 22:16 ` [PATCH 14/17] riscv: poison SBI calls " Christoph Hellwig
2019-06-10 22:16   ` Christoph Hellwig
2019-06-10 22:16 ` [PATCH 15/17] riscv: don't allow selecting SBI-based drivers " Christoph Hellwig
2019-06-10 22:16   ` Christoph Hellwig
2019-06-10 22:16 ` [PATCH 16/17] riscv: use the correct interrupt levels " Christoph Hellwig
2019-06-10 22:16   ` Christoph Hellwig
2019-06-10 22:16 ` [PATCH 17/17] riscv: add nommu support Christoph Hellwig
2019-06-10 22:16   ` Christoph Hellwig
2019-06-11 10:32   ` Vladimir Murzin
2019-06-11 10:32     ` Vladimir Murzin
2019-06-11 12:44   ` David Hildenbrand
2019-06-11 12:44     ` David Hildenbrand
2019-06-24  5:42 RISC-V nommu support v2 Christoph Hellwig
2019-06-24  5:42 ` [PATCH 02/17] mm: stub out all of swapops.h for !CONFIG_MMU Christoph Hellwig
2019-06-24  5:42   ` Christoph Hellwig

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=80d01a1d-b6b0-18e8-811c-71af14cba3b9@arm.com \
    --to=vladimir.murzin@arm.com \
    --cc=damien.lemoal@wdc.com \
    --cc=hch@lst.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=palmer@sifive.com \
    --cc=uclinux-dev@uclinux.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.