Re: fs: dax: do not build on ARC or SH

Re: fs: dax: do not build on ARC or SH

[Matthew Wilcox]

On Mon, Feb 23, 2015 at 12:29:45PM +0100, Arnd Bergmann wrote:
> The DAX implementation relies on the architecture to provide a working
> copy_user_page() function, as reported by Michael Ellerman's kisskb
> build bot:
> 
> fs/dax.c: error: implicit declaration of function 'copy_user_page' [-Werror=implicit-function-declaration]:  => 266:2
> 
> We already have a list of architectures that are known to be incompatible,
> but the list is missing ARC and SH at the moment. Further, blackfin and
> c6x also lack support for this function, but are already excluded because
> they do not support MMU-based kernels.

I've got a short list of patches for DAX; I'll add this one to the list.

Have the maintainers of these architectures been notified that they're
missing a core piece of kernel functionality?

Re: fs: dax: do not build on ARC or SH

[Arnd Bergmann]

On Monday 23 February 2015 13:40:25 Matthew Wilcox wrote:
> On Mon, Feb 23, 2015 at 12:29:45PM +0100, Arnd Bergmann wrote:
> > The DAX implementation relies on the architecture to provide a working
> > copy_user_page() function, as reported by Michael Ellerman's kisskb
> > build bot:
> > 
> > fs/dax.c: error: implicit declaration of function 'copy_user_page' [-Werror=implicit-function-declaration]:  => 266:2
> > 
> > We already have a list of architectures that are known to be incompatible,
> > but the list is missing ARC and SH at the moment. Further, blackfin and
> > c6x also lack support for this function, but are already excluded because
> > they do not support MMU-based kernels.
> 
> I've got a short list of patches for DAX; I'll add this one to the list.

Ok, thanks!

> Have the maintainers of these architectures been notified that they're
> missing a core piece of kernel functionality?

Not until you put them on Cc here.

	Arnd

Re: fs: dax: do not build on ARC or SH

[Guenter Roeck]

On Mon, Feb 23, 2015 at 01:40:25PM -0500, Matthew Wilcox wrote:
> On Mon, Feb 23, 2015 at 12:29:45PM +0100, Arnd Bergmann wrote:
> > The DAX implementation relies on the architecture to provide a working
> > copy_user_page() function, as reported by Michael Ellerman's kisskb
> > build bot:
> > 
> > fs/dax.c: error: implicit declaration of function 'copy_user_page' [-Werror=implicit-function-declaration]:  => 266:2
> > 
> > We already have a list of architectures that are known to be incompatible,
> > but the list is missing ARC and SH at the moment. Further, blackfin and
> > c6x also lack support for this function, but are already excluded because
> > they do not support MMU-based kernels.
> 
> I've got a short list of patches for DAX; I'll add this one to the list.
> 
> Have the maintainers of these architectures been notified that they're
> missing a core piece of kernel functionality?
> 

Guess there a philosophical difference in opinion if the architecture code
should (have to) provide copy_user_page() or not outside the architecture
code itself. After all, fs/dax.c _is_ the only user of this function outside
the architecture code.

Guenter

Re: fs: dax: do not build on ARC or SH

[Christoph Hellwig]

On Mon, Feb 23, 2015 at 01:56:34PM -0800, Guenter Roeck wrote:
> Guess there a philosophical difference in opinion if the architecture code
> should (have to) provide copy_user_page() or not outside the architecture
> code itself. After all, fs/dax.c _is_ the only user of this function outside
> the architecture code.

Given that copy_user_page just is an optimized version of copy_page
all these architectures should just grab the trivial macro defintion
from the asm-generic version so that we could avoid this discussion.

Re: fs: dax: do not build on ARC or SH

[Guenter Roeck]

On Mon, Feb 23, 2015 at 01:58:47PM -0800, Christoph Hellwig wrote:
> On Mon, Feb 23, 2015 at 01:56:34PM -0800, Guenter Roeck wrote:
> > Guess there a philosophical difference in opinion if the architecture code
> > should (have to) provide copy_user_page() or not outside the architecture
> > code itself. After all, fs/dax.c _is_ the only user of this function outside
> > the architecture code.
> 
> Given that copy_user_page just is an optimized version of copy_page
> all these architectures should just grab the trivial macro defintion
> from the asm-generic version so that we could avoid this discussion.
> 
I tried to do just that, for mips, with little success.

https://patchwork.linux-mips.org/patch/9175/

Presumably, if copy_page() followed by a conditional flush_data_cache_page()
does not work on mips, I would assume that copy_page() without flush does not
work either.

Guenter