Hi Arnd,
On 19/04/11 18:21, Arnd Bergmann wrote:
On Tuesday 19 April 2011, Greg Ungerer wrote:
On 18/04/11 06:13, Arnd Bergmann wrote:
If so, what are these
syscalls supposed to do in that case? I assume that they don't actually
change the physical location of a virtual address.
Since the unistd.h file is shared with m68k, I see nothing wrong here,
they should simply get stubbed out like the other NOMMU syscalls (swapon,
mprotect, msync, ...)
I have no objection to changing these to be sys_ni_syscall for the
CONFIG_MMU=n case of m68k. I am pretty sure they will never have
been used in any way on m68knommu systems. (It does look like uClibc
for example does support these even on no-mmu systems though. I just
don't think they will have actually been used by anyone).
They are already sys_ni_syscall, by means of kernel/sys_ni.c.
I wouldn't bother changing them. The real question is whether
you should define the __NR_* macros for the syscalls that are
not provided. For a new architecture I think you should not,
but removing them might cause regressions. Then again, it's
probably very useful to match the unistd.h file with the system
call table.
Ok, then it looks like we don't need the long redefine list
for the non-mmu case in Geert's original patch.Those that are
not implemented by the non-mmu build will just end up being
sys_ni_syscall anyway.
I built (and run tested) that for m68knommu targets, removing
the redefine list - expect for sys_mmap2/sys_mmap_pgoff - and
that of course works fine.
Regards
Greg
------------------------------------------------------------------------
Greg Ungerer -- Principal Engineer EMAIL: gerg@xxxxxxxxxxxx
SnapGear Group, McAfee PHONE: +61 7 3435 2888
8 Gardner Close FAX: +61 7 3217 5323
Milton, QLD, 4064, Australia WEB: http://www.SnapGear.com
--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
