On Sat, Aug 26, 2017 at 03:46:22PM -0700, Dan Williams wrote: > On Sat, Aug 26, 2017 at 12:50 PM, Helge Deller <deller@xxxxxx> wrote: > > On 26.08.2017 17:15, Dan Williams wrote: > [..] > >> I have not seen any patches for parisc pmem+dax enabling so it seems > >> too early to worry about these "last mile" enabling features of > >> MAP_DIRECT and MAP_SYNC. In particular parisc doesn't appear to have > >> ARCH_ENABLE_MEMORY_HOTPLUG, so as far as I can see it can't yet > >> support the ZONE_DEVICE scheme that is a pre-requisite for MAP_DIRECT. > > > > I see, but then it's probably best to not to define any MAP_DIRECT or > > MAP_SYNC at all in the headers of those arches which don't support > > pmem+dax (parisc, m68k, alpha, and probably quite some others). > > That way applications can detect at configure time if the platform > > supports that, and can leave out the functionality completely. > > Yes, that's a good idea we can handle this similar to > CONFIG_MMAP_ALLOW_UNINITIALIZED. These patches will also modify > 'struct file_operations' so that do_mmap() can validate whether a flag > is supported on per architecture basis. Also the plan is to plumb the > flags passed to the syscall all the way down to the individual mmap > implementations. The ext4 and xfs ->mmap() operations will be able to > return -EOPNOTSUP based on runtime variables. BTW, we may be able to reuse the bit used for MAP_UNINITIALIZED -- it's only used on !MMU machines. -- Kirill A. Shutemov -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
