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.
- sys_fork, although it returns -EINVAL, not -ENOSYS
I can't recall why it is that way :-)
For one thing uClibc doesn't even generate a library symbol for it.
So the only way someone would be able to get to it normally on an
m68knommu system is to code the raw system call. And even then all
they will ever get is a fail. I doubt the change in errno return
type would be a problem.
I have no problem with being consistent with asm-generic/unistd.h,
and stubbing this to a sys_ni_syscall as well.
Makes sense. Note that the man page defines neither return code.
M68knommu does not implement:
- sys_mremap
- sys_nfsservct
Shouldn't you get a warning about these from scripts/checksyscalls.sh ?
It doesn't complain.
Ah, you actually define the syscall numbers for these, so it will not warn,
despite the fact that the entry is missing.
mremap should really work, except for MREMAP_FIXED, as documented in mm/nommu.c.
nfsservctl is probably not needed, but I see no reason to leave it out either.
They should work exactly the same as any other non-mmu arch.
I just compile tested with those enabled (as per asm-generic/unistd.h)
and it worked fine. So I would be happy to see those removed from the
stub list for m68k/m68knommu.
Ok, good.
Arnd
--
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
